robustness vs. conservative GC

[Tom Lord <lord at regexps dot com>]

All this discussion of the virtues and vices of conservative GC is
interesting, but don't forget that the project announcement ("Subject:
a .NET alternative (GJC et al)") is for a run time system with more
features than simply exact GC.

The goal of the project announcement is to rally participation and
support for the project, not to engage in a long debate about GC.

But here's my answer to two good questions that've come up on the list
and in private replies:

	> The robustness problems [of conservative GC] are much larger
	> than just that one issue. 

	Care to elaborate?

Here are some of the robustness problems with conservative GC, as I
see it:

1. When using a conservative GC, no object is guaranteed to be
   collected.  Thus, programmers are denied an important element
   of control over resource usage.  This has some consequences;


1a. If one large object or many smaller objects are never 
    collected, substantial amounts of storage are leaked.

1b. If an object holding a precious resource is never collected,
    that resource is leaked.  File descriptors and X11 windows
    are two examples of precious resources.

1c. If the natural way to write a program is to have the program take
    some action when or after a finalizer is executed, that program
    won't always run correctly.  I think the Java standard permits
    implementations of this sort and discourages reliance on
    finalizers but that doesn't make such implementations desirable.
    
    Also, one goal of the Hackerlab C Library is to support more
    languages than just Java.

1d. The usefulness of weak references is undermined.

Sometimes people reply to these problems by saying ``The programmer
should be responsible for explicitly deallocating such objects'' which
is a practical work-around in some situations, but not a general
solution.  Having to explicitly deallocate objects is a pretty strong
constraint on programming style -- I'm not sure it's better than not
using GC at all.



2. In the face of an aggressively optimizing C compiler, one that
   sometimes disguises pointers, conservative GC can fail to protect
   some live objects, resulting in program failures.  This is a 
   famous limitation of conservative GC.

   Sticking to a specific compiler and options known not to disguise
   pointers avoids the bug, but is a fragile solution.

   Another way to avoid this bug is with coding tricks that prevent
   pointer-disguising optimizations from taking place.  If you'll go
   to that trouble, you may as well use a precise collector instead.
   It's not quite that simple a trade off, because there are
   performance issues involved, but we don't know a priori which
   approach will be faster.


In my experience, both bugs (#1 and #2) are likely to eventually show
up in deployed systems, but they can't be relied upon to show up when
you're testing.  You are best off recognizing them from first
principles.

Fergus Henderson made the claim that an exact GC implemented without
compiler support is likely to perform worse than one implemented with
compiler support.  I don't know what "likely" means in that claim, but
I don't see any a priori reason to believe there will necessarily be
performance problems.  Does anyone else?


-t

-- 

Rent is coming due!
Visit http://www.regexps.com.  Spend money.