From: Alexandre Oliva (oliva@dcc.unicamp.br)
Date: Thu Dec 17 1998 - 16:13:13 EST
On Dec 17, 1998, Godmar Back <gback@marker.cs.utah.edu> wrote:
> Okay, I don't understand your proposal.
> How do you want to prevent difficulties from reattachment
> attempts in the finalizer? Or other attempts to use data structure
> deallocated in the quasi-finalizer?
The suggestion is that, for objects that whose finalizer might make
them alive again, we should have two quasi-finalizers: the first one
would just create the second one and arrange that the first object
points to it. So, the quasi-finalizer would look like this:
Object quasiFinalizer = new Cloneable() {
private boolean really = false;
public void finalize() {
if (really)
finalize0();
else {
quasiFinalizer = clone(); // avoids needing a constructor
quasiFinalizer.really = true;
}
}
}
Notice that it is pessimistic, by assuming that reallyFinalize is
false. It could be made true if the primary object had a trivial
finalizer, but I don't think we can easily check that in Java.
This works because both objects will become unreachable at the same
time, and then both finalizers will be run. Even if the Thread
finalizer() doesn't make the Thread reachable again, the new
quasiFinalizer's will, since it will be reachable, and will point to
the Thread. But then, whenever the Thread becomes unreachable again,
so will the second quasiFinalizer, but now, Thread's finalizer() won't
be run, so it is safe to actually finalize it.
Isn't this really worth a paper? :-)
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:20 EDT