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

[Corey Minyard <minyard@acm.org>]

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.

-- 
Corey Minyard               Internet:  minyard@acm.org
  Work: minyard@nortel.ca       UUCP:  minyard@wf-rch.cirr.com