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

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Joe says

<<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.>>


The issue of implicit heap access is a critical one in any Ada technology.
This is *especially* true of embedded use. In the design of GNAT, we have
followed the general philosophy of minimizing implicit heap use. The only
times that the heap is used implicitly are the following:

1. Creation of tasks
2. Allocation of the secondary stack for tasks

We specifically do NOT use the heap for management of variant records.
Instead, we always allocate the maximum size where appropriate.

Note that an implementation (at least one that conforms to annex H) is
required to document where it uses the heap implicitly, see RM D.7:

8   No_Implicit_Heap_Allocations
                There are no operations that implicitly require heap storage
                allocation to be performed by the implementation.  The
                operations that implicitly require heap storage allocation
                are implementation defined.