Re: Ammo-zilla

[Tucker Taft <stt@averstar.com>]

David Starner wrote:
> ...
> As a side question: Ada 95's designers must have been familiar with Modula 3's
> support of garbage collection while letting real time stuff keep track of
> its own memory. What stopped them from adopting something like that for
> Ada 95?

Another good question...

First, I agree with you that you can't really depend on garbage
collection in a langauge until essentially all implementations provide it,
so saying that it is allowed is sort of irrelevant.  On the other hand,
if you happen to be focusing on the Ada->JVM target, you can presume that
all implementations (there are only 2 so far) will provide garbage collection,
as it is built in to the JVM.

One choice you have is to use the third-party "conservative" garbage
collectors, essentially the same choice as provided by C++.  These
work with the same caveats in both Ada and C++.

As far as why we didn't have garbage collection for some kinds of
memory, and not for others, it was a question of demand, and perceived
cost/benefit ratio for a language focused on "critical" systems.  Prior to
the arrival of Java, garbage collection was definitely not "mainstream."
In the long run, making garbage collection a "mainstream" language feature
may be Java's biggest contribution to the history of programming language
usage.

On the other hand, our local experience with Java and garbage collection
is that the value it provides is greatest during prototyping.  Once you
get serious about scalability and performance, you have to go back to
being extremely careful about unnecessary object creation, and about 
effectively "freeing" objects (by nulling-out pointers) as soon as possible.
It is true that you don't have to worry about freeing memory too soon,
but you do have to worry about making sure that objects do not remain
unintentionally "reachable."

Personally, I think garbage collection is a way-station toward some
better as-yet-to-be-determined approach.  There are some interesting
languages and languge-theories out there that are based on single-point-of-
access to objects.  The language Hermes (nee' "Nil") by Strom et al had
this as their fundamental storage management approach.  It makes a lot
of sense for distributed and/or multi-threaded computing, because it
addresses storage management, synchronized access, and distribution
in one nice package.

Getting back to your original question about why not have garbage collection
for some kinds of objects, and not for others.  Once storage management gets
this sophisticated, it begins to become more of a "programming problem" than
a "language problem."  There were bad experiences with Ada 83 when the
language tried to get too high-level, to the point where the programmer
had no intuition about the implementation model of the language feature,
and implementations varied widely in the relative performance characteristics
of different features.  

Ideally, the ability to do garbage collection could be 
handed over to the programmer in a way that allowed them to
carve up the overall heap space into separate pools with different
management approaches in each, and then the programmer, or some third
party, would provide managers for these various spaces.  We took a baby-step
in that direction with the Storage_Pool attribute, but we didn't feel
confident in doing too much invention in this area.  Luckily, the
Ada language design process is much more dynamic now than it was in the
period from 1983 to 1990, so as good ideas are proposed and prototyped
(perhaps using GNAT), there is a very real chance that they will evolve
into parts of the standard.  

I know that some users of Ada 95 have built quite elaborate 
garbage collectors on top of the Storage_Pool facility
(e.g. the garbage collection built into the ORBExpress/Ada product built
by Objective Interface Systems).  Perhaps their experience will enable
us to develop a more complete user-controlled garbage collection capability
for future standardization.  

For this to be most useful, there *will* need to be a 
garbage-collecting storage pool manager defined as part of
the standard, so it may be used in all Ada code, not just in code written
for a compiler that happens to include one.  Certainly a key requirement
will be that this garbage-collecting manager is not forced on all Ada
users, and that it is replacable by the programmer or a third party without
having to go back to the compiler vendor, and without having to dismember
the rest of the run-time system.  It would not be acceptable to follow
the Java approach, where garbage collection is an integral part of the
JVM, with no well defined way to avoid it or replace it without essentially
rewriting the JVM. 

> --
> David Starner - dstarner98@aasaa.ofe.org

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA