[gclist] What does a garbage collector do about

[David Chase]

At 3:27 PM +1000 7/28/02, Steven Shaw wrote:
>Even though you can throw an exception from a destructor. I don't think
>you can catch exceptions throw from super destructors in your overriding
>destructor.

I tend to think of C++ as its very own special case.

>How does running finalisers in another thread help?
>Would you mind posting about the other possibilities?

The annoying problem with finalizers is that they run in
a funny context, and (as done in Java) it's a pain to make
the context un-funny, if it can be done at all.  This is
partly a result of Java's security model and the resulting
tendency to regard all user code as a potential adversary.

So, for example, a Java runtime has to protect itself from
finalizers that do not terminate.  It also has to run
finalizers in a sort of least-common-denominator security
context (else a malicious applet could use a finalizer to
commit crimes).  There was also a decision to queue an
object for finalization only once, which avoids a fair
number of what-if scenarios with resurrected objects
and finalization order (programmers are thus "encouraged"
to not resurrect objects post-finalization).

If you were doing it over, one thing that might make
sense is to let a ThreadGroup (for example) designate
a queue on which unreachable (hence, finalizable) objects
should be placed.  This means that the ThreadGroup can
set the policy for the objects that it allocates, and
either drop them on the floor, or poll the queue and
run them synchronously, or designate a thread to poll
the queue.  This is similar to how weak references are
dealt with, except that the finalizable objects are
visible to the finalizer.

The main advantage here is that it gives the client
application the responsibility for its own finalizers,
and it allows the client application to set or reuse
the context in which they are run.  It doesn't solve the
problem of applications that claim to have committed
an operation, without actually doing the necessary file
I/O for a commit; that is a bug, plain and simple.

David Chase