Re: Java-Ada95 comparisons

Mark Johnson wrote:
>[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".


[Warming up the flame throwers...]


I think you're misstating the benefits of garbage collection. You
seem to be saying that the main benefit of a garbage collector is that
they deal well with low-memory situations; I don't think this is true
in many cases. A garbage collector certainly causes less memory usage
by avoiding memory leaks. However, a GC will often cause thrashing in
the garbage collection phase on VM machines when real memory is full.
Some garbage collection techniques require substantially more memory
during the collection, for instance a semispace copying collector. It
is true that a compacting collector will save some memory by
rearranging blocks to avoid fragmentation as the MacOS memory manager
does. However, Paul Wilson (wilson@cs.utexas.edu) has found that in
practice with a good allocator fragmentation doesn't cause much loss.


I think that the major benefits of garbage collection are increased
program reliability and ease of programming. As an excellent example
of the former, consider the Macintosh memory manager. While it is
pretty good at avoiding fragmentation, it is legendary for causing
subtle, hard-to-find bugs. A classic is passing a pointer to a
relocatable block to a routine. In most cases, there will be no
problems. However, if the routine causes a heap compaction, the
pointer will become invalid. This type of bug, while easy to fix, is
rather hard to detect. I suspect that a large proportion of crashes
on the Mac are due to this type of error. I know that as a Mac
programmer I've spent a lot of type tracking down this type of bug.


As for the latter point, the difficulty of writing code for a manual
allocator, I've been pleasantly surprised by the experience of writing
a ray tracer for a class recently. Part of the task is building up a
DAG representing the scene. For efficiency's sake, a node
representing an object may have many references. My friends using
manual allocators were using reference counts and seperate linked
lists to properly deallocate the objects (or ignoring the issue). I
didn't have to worry about the issue, since I was using a GC. Many
situations involving data structure manipulations are made simpler by
GC.


As for dealing with low memory situations, I don't think a garbage
collector really changes things at all. If memory runs out, both a
manual allocator and a GC will fail in the same way. The one
advantage I can see to GC in low-memory situations is that cleanup
might be easier. A good way to deal with running out of memory (one
which I haven't seen in use much) is to throw an exception. GC might
help considerably in this situation, since no explicit work has to be
done to clean up the objects which are no longer referenced after the
exception is caught. With manual allocation, all intermediate
routines have to catch the exception, clean up stuff, and rethrow
(although C++ destructors can make some of this automatic). This
cleanup code is pretty much impossible to thouroughly check for leaks
and errors.


Seth
--

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