Re: Java-Ada95 comparisons

Saileshwar Krishnamurthy <krish@cs.purdue.edu> wrote:
>It also says:
>
>"Another interesting (or shall I say "striking") aspect is that the
>Java virtual machine includes garbage collection. This means that we
>will soon have access to the first Ada system that collects garbage,
>should any be left around... In other words, this is the end of the
>mythical, or was it mystical, garbage collector allowed but not
>required by the Ada reference manual."
>
>Does this "mythical" GC-er exist in Ada95 as well ?




Well, a brief review of the "Annotated Draft" of the Ada language
standard reveals a pretty lengthy discussion of the issues related to
garbage collection. There is an "Implementation Permission" which
states...


    An implementation need not support garbage collection, in which
    case, a pragma Controlled has no effect. [AARM 13.11.3(6)]


There are a number of rules that the garbage collector must follow if
it is implemented, most are related to object finalization.


In practice, almost ALL Ada implementations have been developed w/o
garbage collection. One implementation that did have garbage
collection was for the Symbolics [RIP]. In that case, the garbage
collection was a general capability of the system that the
implementation used to some benefit. In other cases, it was deemed
"too hard" or "without user benefit" by the developers.


[now donning a flame proof suit]
To a certain extent, this is skating around the issue of the benefits
of garbage collection. I am composing this message on a Macintosh
which uses techniques similar to garbage collection (e.g., use of
handles, dynamic loading & purging of resources). It allows me to
operate in "low memory" situations quite well in most cases. Some
programs don't handle that very well & crash or "lose my work".


I don't think adding garbage collection to the system would help much.
The program still has to break the links to the "garbage" - otherwise
there is nothing to collect. If it does that, it should look to
deallocate the memory explicitly instead. Then garbage collection
isn't necessary.


In that case, I'd argue that garbage collection has little or no value
for properly constructed applications. I can see that the Java
runtime needs a robust mechanism for reclaiming storage from the
applications running. If they chose garbage collection, so be it.
There are certainly good alternatives out there that provide the same
or similar benefit to the user w/ different performance and storage
characteristics.


    --Mark
-- Mark Johnson <mjohnson@samson.tx.hac.com>
[The argument can be made that getting a "properly constructed" application
to manage its storage perfectly is very difficult, given that nearly every
program that uses malloc() seems to have storage leaks. GC makes it a lot
easier to wrote correct programs since a whole range of errors just
disappear. -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.