Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

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

Dave Jones said

  "BTW:  I have heard that, for C++, someone has written a garbage
  collector which can be added to almost any C++ program.  Would it be any
  more difficult to do the same thing for Ada95?  I would certainly look
  forward to such a product.  IMHO, memory management is something that a
  machine should do (whenever possible) -- freeing up humans to do things
  which require more skill and creativity."

Well sentences that start "I have heard that" most often end with something
wrong at worst and misleading at best :-)

In fact it is impossible to provide a general garbage collector for typical
implementations of C++ (there simply is not enough runtime information around).
What you have heard about is conservative garbage collectors that make
the basic assumption that a block is dead if there is no word in memory that
*could* be a pointer to or into the block.

This assumption is (a) inadequate, as someone pointed out here recently,
the use of virtual origins can upset this assumption and result in blocks
being collected which are in use and (b) too strong, blocks that are not
in use can be held by integers that accidentally mimic pointers.

That being said, this kind of conservative garbage collection can work
quite well in some applications, and is of course equally applicable to
Ada 95 as it is to C++.

By the way, a little history. Ada was originally designed with the expectation
that garbage collection would be available in typical implementations. Look at
the description of pragma Controlled to get a feel for this. However, almost
no implementations provided GC. During the Ada 95 development effort I made
the suggestion that we at least "require" GC for the information systems
annex, but other people found this laughably unrealistic, and there was zero
support inside and outside the Ada 9X design group, DR's and ISO for such a
step. Note of course that Ada 95 certainly *permits* garbage collection, and
the design was carefully carried out to ensure that this is the case, but
there was no sympathy for trying to require it (the requirement of course
would be a somewhat wooly one, since GC is not something you can specify
formally, but there are plenty of other wooly requirements like this already.

It is possible that Java will reorient people's thinking regarding garbage
collection. However, there are some things to bear in mind.

1. There are significant efficiency issues that have to be faced. Of course
in an interpretive environment like JVM, these are completely swalled up by
the interpretive overhead in any case.

2. The mixture of GC with low level features like pointer mucking is a very
worrisome one, because anything that upsets the integrity of the pointer
structures can cause unimaginable chaos in a garbage collected environment.
(bitter experience debugging SPITBOL compilers remembered here :-)

3. The mixture of GC with real time continues to worry a lot of people. This
statement will of course bring a certain advocate of real time GC out of his
silence, but the fact is that Henry Baker has not managed to convince the
world on this point yet, despite a lot of effort on his part.

4. There are some worrisome interactions between garbage collection and
finalization that have to be sorted out, and between garbage collection
and other features, such as ATC.