GC in Ada

[macrakis@HARVARD.HARVARD.EDU (Stavros Macrakis)]

A few weeks ago, there was a query about garbage collection in Ada.
I've assembled a few notes on the subject.

Several Ada systems appear to have garbage collectors (GC) in
development environments (e.g. Rational, Symbolics).  As far as I have
been able to ascertain, no production Ada environment provides garbage
collection in the target computer.

The usual argument is that embedded applications shouldn't GC, because
GC is inefficient and episodic.  This is spurious for several reasons:

 1. Prototypes and early development versions may prefer to sacrifice
    efficiency for simplicity and speed of programming.

 2. Many Ada applications will in fact not be embedded.

 3. If you have GC, it is very easy to add a capability to detect and
    report undeallocated objects and dangling pointers.

 4. Embedded applications may even want GC.  Traditional episodic GC
    will do for some; others will need real-time GC algorithms.

 5. GC may not be as expensive as is thought, especially if currently
    known advanced implementation techniques are used.

 6. Given Ada's typing, scoping, and tasking, much processing can
    continue even during episodic GC.

However, implementing a GC for Ada is not entirely trivial.  Although
Ada's semantics certainly allow GC, some compiler-writers may have
chosen runtime models which make it impractical or impossible.  Not
only must pointers in memory be traceable, but transient `hazards'
must be avoided.  The conditions are even more stringent for
relocating/compacting GC, of course.

The only current compilers I know the internals of, the Intermetrics
Byron Ada compiler family, have their runtime model carefully designed
to in fact make GC practical.  However, no customer so far has
specified GC.  I'm sure Intermetrics would be happy to sell a GC
option as soon as the market demand became sufficient.

	-s

	Stavros Macrakis
	Harvard Univ. and Intermetrics, Inc.