Re: Java-Ada95 comparisons

mjohnson@samson.tx.HAC.COM (Mark Johnson) writes:


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


At the risk of revisiting old arguments: (I assume we're no longer
talking about hard real-time systems, which involve different issues.)


Garbage collected systems rarely break links explicitly. Objects
usually become garbage as a result of overwritten pointers or lost
bindings as a result of procedure returns. In extremely rare cases,
there are performance reasons for explicitly clearing links. Usually
the failure to do so, only results in a fixed size, not growing, leak.
Even explicitly clearing links is much easier than explicit
deallocation for two related reasons:


1. It is a local problem. I have never seen garbage collected code
that attempted to (or needed to) clear links in a data structure it
shared with another module. In explicitly managed code, explicit
deallocation of data structures referenced from more than one place is
the heart of the problem. I clear the link to the shared data
structure when I no longer need the shared data structure. The other
module clears it's link. We don't need to agree who is last.
(Agreeing who's last can also be expensive. See
ftp://parcftp.xerox.com/pub/gc/example.html.)


2. It is safe, and errors are easy to trace. If I mistakenly clear a
pointer, I will get a nil-pointer dereference, and I will immediately
know which pointer was mistakenly cleared. If I prematurely
deallocate an object, it may be reallocated before it's referenced
again. In that case, the fault can show up with arbitrary symptoms in
an arbitrary module in the system.


Hans-J. Boehm
(boehm@parc.xerox.com)
--

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