Re: Java-Ada95 comparisons

mjohnson@samson.tx.HAC.COM (Mark Johnson)
30 Jan 1996 18:25:02 -0500

          From comp.compilers

Related articles
Possible to write compiler to Java VM? (I volunteer to summarize) seibel@sirius.com (Peter Seibel) (1996-01-17)
Re: Possible to write compiler to Java VM? hbaker@netcom.com (1996-01-29)
Java-Ada95 comparisons krish@cs.purdue.edu (Saileshwar Krishnamurthy) (1996-01-29)
Re: Java-Ada95 comparisons mjohnson@samson.tx.HAC.COM (1996-01-30)
Re: Java-Ada95 comparisons boehm@parc.xerox.com (1996-02-02)
Re: Java-Ada95 comparisons sethml@ugcs.caltech.edu (1996-02-09)
| List of all articles for this month |

From: mjohnson@samson.tx.HAC.COM (Mark Johnson)
Newsgroups: comp.compilers
Date: 30 Jan 1996 18:25:02 -0500
Organization: Hughes Training, Inc.
References: 96-01-037 96-01-100 96-01-105
Keywords: Ada, GC, comment

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]
--


Post a followup to this message

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