[gclist] Finalizer flame wars.

[David Chase]

> From: bobduff@world.std.com (Robert A Duff)

> Is the application programmer less trustworthy than the person writing
> the gc?

Yes, absolutely.  There are relatively few GC-writers in this
world, and the ones that I know have been studying the problem
(correctness, efficiency, portability, per-platform quirks) for
about a decade.  I've been working with the Boehm-Weiser collector
on and off for 9 years now, and playing with garbage collection in 
various forms for about 14 years.

> The alternative is the paternalistic attitude that says only the
> language implementer can play dangerous games.  That's fine when it
> works, but in *some* cases, it will cause people not to use gc at all.

Yes, for a certain value of dangerous.  For instance, humans (at 
least those posting to the net) have proved themselves to be very 
bad at correctly performing the sort of simple optimization that 
compilers do right all the time.  Note how many times people blow 
stupid stuff, like "x/2" translated into a shift (not so simple if 
x is negative).  Or, consider translating a "x <,=,> y" comparison 
into negative, zero, positive, by writing "x - y".  People are generally 
unreliable.  Implementors are unreliable too, but they're typically 
experienced and/or overeducated, and a compiler *ought* to be very 
thoroughly tested (I estimate that the last optimizing C/C++/Fortran 
compiler I worked on was run through perhaps a CPU-decade of testing
during its development, though much of that was redundant).

But, in the case of garbage collection, I've got no problem with 
user controls to suppress garbage collection at certain points, nor 
am I bothered by weak pointers.  Finalization is ok *IF* it is clear 
that the implementor and the programmer agree on what it is supposed 
to mean.  If its limitations are clearly understood, there is no 
problem. 

> >...For
> > example suppose a user defined mark method failed to mark an object
> > that was actually in use. 

User-defined mark methods are probably a bad thing.  Sorry to be 
paternalistic, but there's scant evidence that they save time, more 
evidence that they cost time, and their potential for bug-creation 
is obvious.

> > So as a language designer I opt for transparent. The user should be
> > unaware of the collector. I am considering the option of saying the
> > language protects the user from himself unless he says I know what I'm
> > doing leave me alone. For example assignments are rigidly type checked
> > unless the user says something like "shove".  But the execptions where
> > the user tells the language to bug off should be very rare.

> They should be rare, and should be isolated.

Gee, I'd hate to plug my favorite procedural language, but Modula-3 
has done a nice job here.  Consider also that these problems have 
been studied, and people (formerly) associated with Xerox PARC and 
DEC's research labs have arrived at the conclusions that: 

1.  GC is good.
2.  Finalization using the explicit request model is also good,
    and the problems caused by cycles of finalizable garbage are
    extremely rare.  Timely finalization is not an absolute necessity,
    nor is certain finalization.

Note that #2 says ab-so-lutely nothing about finalization==C++ destructors,
nor does it say anything about finalization as it exists in Java.  
By-the-way, there's a nifty looking little state machine that I've 
seen which "explains" how finalization works in Java, and it would 
be a good idea to build one of these for how finalization works in 
other languages.  I'll see if I can get permission to release the 
Java Finalization state machine, and I'll try to write one up for 
Modula-3 (as I understand it).  I think concreteness would help to 
reduce the temperature of the flame war.

David Chase