[gclist] Put unnessisary code inside #if 0 #endif not finalizers.

boehm.PARC@xerox.com boehm.PARC@xerox.com
Thu, 4 Apr 1996 10:26:37 PST


File descriptors are a somewhat confusing example here because they are a
ridiculously scarce resource in some environments, and not so scarce in others.
Most Unix-like operating systems seem to have a real maximum of around 1000,
which in my opinion makes it quite feasible to manage them at least partially
with finalization.

Even if you only have 20 file descriptors available, there are some reasons to
consider this approach:

1.  It's still a useful backstop, even if you don't expect to drop any
descriptors.
2.  For some applications, 20 file descriptors will be too few to get real work
done anyway.  Thus the application will need to use some caching scheme.  The
application will manage its own mapping of logical file descriptors to file
state.  When you run out of descriptors, you close a rarely used one and
remember enough of its state so that you can reopen it (which is hopefully
possible).  This reduces the problem back to the one with a large number of
available descriptors.

Charles writes:

"In short conservative collection is a kludge. Language support is always
better."

One man's kludge is another man's engineering tradeoff.  Some language support
is almost always better than none, if you have the choice.  But I believe that
maintaining complete pointer information, particularly for the top stack frame
is often not worth the cost.  But we've been through this before.

"Finalizers in the collector are a kludge. Language support for
a prompt and sure mechanism must be better."

Yes, provided it doesn't have other costs.  I personally think it's crucial
that I can, at least occasionally, reference OS resources or manually managed
memory from an arbitrary garbage collected data structure (which may be the
only reference), without introducing long-term, unbounded leaks of those
resources.  The "cord" data structure implementation that's packaged with our
collector relies on this, for example.  I don't see how Charles' proposals let
me do this.

I agree with Marc Shapiro that finalizers (esp. the Smalltalk variant) are very
similar or identical to weak pointers + periodic scanning.  You can more or
less implement either one with the other.  (If I remember correctly, Barry
Hayes' paper also makes this observation.)  But I don't think that resolves the
disagreements.

Hans-J. Boehm
Standard disclaimer ...