Re: Beware: Rep spec on an enumeration type causes code explosion

[gwinn@res.ray.com (Joe Gwinn)]

In article <m267p2p27b.fsf@wf-rch.cirr.com>, Corey Minyard
<minyard@acm.org> wrote:

> gwinn@res.ray.com (Joe Gwinn) writes:
> > 
> > Memory Management.  The Ada Runtime System makes extensive calls to the C
> > functions malloc() and free(), a cause for worry.  Variable-block
> > allocators such as malloc and free are generally unsuited for nonstop
> > heavy use, and will generally either leak memory or fragment their memory
> > pool, causing the application to run slower and slower until it eventually
> > jams.   The use of free() in a realtime system is generally forbidden;
> > it's OK to allocate a bunch of memory during startup, and explicitly
> > manage it yourself during operation, but it is not OK to use malloc and
> > free for realtime memory management.  The claim is that Wind River's
> > version of malloc/free is stable in realtime use.  It's hard to see how
> > this could be true.   This will need further research.  
> > 
> 
> Although this is not Ada related, I ran into this, too, when using C.
> The VxWorks implementations of malloc() and free() are very bad, they
> are slow and their speed decreases over use (we saw >100ms malloc
> times on every call after a while!).
> 
> I ported GNU malloc, used the standard VxWorks calls to allocate a
> block, and used that instead.  The times remained sub-millisecond even
> after a long time.  Some people in VxWorks have the port, I suggest
> you contact you VxWorks rep for it, since they have probably improved
> it.

As I said in my reply to Tucker Taft, our experience is that only
fixed-block allocators work in embedded realtime, especially when the
system is heavily loaded.  Such allocators have constant performance,
right up to the point of pool exhaustion, and recover instantly when
someone returns some memory.  Variable block allocators as a class run
slower and slower as their pool approaches exhaustion; this is exactly the
wrong behaviour, as it makes worse the effects of the original overload.

Joe Gwinn