Re: Ada GC (was about Java VM)

Henry Baker wrote:
> "However, the single most important reason why Java is a _much_ better
> language than Ada-95 is the fact that Java does garbage collection and
> Ada does not. Twice now, the Ada language people have gone AWOL


and Robert Dewar wrote:
> Garbage collection is a technique for automatic storage management
> that is pretty much language independent. It is a good idea for some


My recollection is that the original Ada language only mandated the
storage management facilities that let you do without a GC (namely
free in some form) but they also designed the language with enough
care that a GC could be included in a language implementation with
ease: little rules like forcing all pointers to be into explicitly
allocated storage (and not into the stack) helped as well as resolving
the dangling pointer problem. But more importantly, Ada is type-secure
and so a well-optimised GC can be incorporated --- in stark contrast
to the inefficient conservative GCs bolted onto C (or worse,
reference-counting GCs on a C subset). It is vital for a good
mark-and-sweep or generational copying GC to know the types of all
valid storage and the kernel set of pointers (the identifiers on the
stack in A68/Ada/F90, the symbol bindings in Lisp).


Languages like A68/Ada/F90 which control storage more tightly than C
allow further optimisations than just a fast run-time GC. There are
relatively easy transforms to convert apparent heap storage onto the
stack (which is still the fastest form of allocation) , and conversely
to use heap storage when stack was asked for to avoid language-implied
copies when promoting values to a longer lifetime. Likewise the
compiler is often able to statically determine the lifetimes of some
storage and insert the explicit free just after the last identified
use (though with some GCs an explicit free can be more trouble than it
is worth).


However there is the point that I suspect Mr Baker is trying to make
that defensive programming in a language where the GC is only an
optional feature in the local vendor's runtime requires one to put in
all the explicit frees in case the program has to be ported to an
environment with no GC. In this regard it is disappointing that Ada
and Fortran 90 provide language syntax for deallocation and (too?)
many systems do not provide a GC.


Final point: I should point out that an optimised efficient GC can be
hard to get right in conjunction with an optimising compiler. And GC
bugs are among the hardest to find!


Regards,
----------------------------------------------------------------------
Dave Lloyd Email: Dave@occl-cam.demon.co.uk
Oxford and Cambridge Compilers Ltd Phone: (44) 1223 572074
55 Brampton Rd, Cambridge CB1 3HJ, UK
--

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