[gclist] Finalizer flame wars.

[Stefan Monnier]

> Collectors need to be efficient and transparent.

Efficient, yes!
Transparent, not necessarily!

> Adding finalizers hurts their efficiency and transparency.

That's probably where we disagree. A tracing collector is an incredible source
of information thanks to the graph traversal it performs. I think it can
be worth adding hooks to the GC to allow programs to take advantage of this
information.
Similarly, I think it can be worth allowing programs to specify a "copying"
operator for some objects that can be used by a stop&copy-style collector
instead of a "bit-copy". The idea is that, since the copying has to take place,
it can be a good occasion to do some semantically non-effecting cleanup (for
instance).

> Finalizers need to be prompt and sure.

If one of your finalizer needs to be prompt and sure, you should probably not
use a finalizer in the first place but rather use explicit finalization.

> Giving them over to collectors destroys both. In encapsulation terms they
> are a match made in hell. 

Obviously, you don't have anything against finalizers, you just want something
else. Maybe you could extend finalizers with options like "be prompt" that
tells the compiler that this finalizer should be called as soon as the object
is not reachable (rather than "as soon as you can"). This would instruct the
compiler to try to stack-allocate the object or to ref-count it or
I don't know what.

It just so happens that stack-allocation is not always possible and that
ref-count is usually expensive (and doesn't mix well with tracing GC if
you neeed ref-count for promptness reasons).

Given the problems posed by the promptness you request, a good current
solution (until we have something better) is to just let the programmer insert
explicit finalization calls.


	Stefan