Re: Does memory leak?

[stt@spock.camb.inmet.com (Tucker Taft)]

Duncan Sands (sands@clipper.ens.fr) wrote:

: Does Ada leak memory?  

No, but some implementations do ;-).

: ...I would like to believe it doesn't, but
: how does it manage not to (without having to use unchecked
: deallocation)?

Implementations of Ada are allowed to support automatic storage
reclamation (garbage collection) of storage allocated using
"allocators" (such as "new T") but few if any do so at this point.

Implementations of Ada are expected to automatically reclaim storage
for local variables, even variables whose size is not known
at compile-time.  This is often accomplished by using a special
mark/release heap (aka "secondary stack") for such local variables.

Note that Ada is more like C++ than Eiffel/Smalltalk in its
overall approach, since objects are by-default stack resident
rather than heap-resident.  In Smalltalk, pretty much everything
lives on the heap, and garbage collection is essential.  
(In Eiffel you can have "expanded" objects which can be 
implemented as stack-resident objects, though the
default remains non-expanded, heap-resident objects.)
In Ada, you can write very large programs that never use allocators 
or the heap.  

This "heap-free" approach will not work as well in conjunction
with Ada 95's "class-wide" types, but explicit recycling of
those objects that do need to be heap-resident can minimize the 
need for automatic garbage collection.  This approach is practical 
because not everything is on the heap -- only what needs to be is.

In Ada 95, users can implement their own storage "pools" which 
could be used to provide some degree of automatic storage reclamation 
for heap objects.  

In any case, most users of Ada who do use allocators, also use 
Unchecked_Deallocation, which is analogous to "free" of malloc/free fame.
("Free" sounds better than Unchecked_Deallocation, but it is really
the same thing.) 

Some Ada users use explicit mark/release, which is typically much 
faster, presuming it matches your application needs.  I would expect more
use of mark/release in Ada 95 now that users can implement
their own storage pools.

The other relevant new features of Ada 95 are user-defined
assignment and finalization, which are analagous to C++ copy constructors
and destructors.  These allow the programmer to get control
when copies are made, or when an object goes out of scope.
These can be used to implement automatic reference-counting-based
management of dynamic storage, which can do the job adequately 
for certain applications.

: For example, if I have a pointer to a block of memory, and I set
: that pointer to null, in simple cases I am ready to believe that
: the compiler knows I'm finished with the block... but if the
: pointer is to a complicated self-referential structure, some sort
: of black magic seems needed to work out whether I'm really
: finished with that structure or not.  Can this truly be done
: efficiently?

Most (all?) current Ada compilers do not provide garbage collection.
Hence setting a pointer to null will not cause any automatic
storage reclamation in such implementations.

Now that general purpose (though some will say potentially "dangerous")
language-independent "conservative" garbage collectors are available,
I would expect more of them will be integrated with Ada implementations.

True "exact" garbage collection can also be implemented in Ada, but
thus far the market demand for it has not matched the expense of
implementation.  It may be that the GNU Modula-3 "exact" garbage collection
support could be adapted to work with the GNU NYU Ada 95 compiler (GNAT).

: You can see that I know nothing about how garbage collection works,
: and precious little about what Ada requires for memory management.
: I suspect I'm not the only one.  If someone could demystify all this
: for me, I would be very grateful...

I hope the above helps a little.

The topic of storage management, and the various religious and 
technical battles associated therewith, can expand to fill whatever
amount of time you have available, so beware...

: Thanks a lot,

: Duncan Sands.

-Tucker Taft   stt@inmet.com
Intermetrics, Inc.