OK, after thinking about it for a while, we are leaning against
trying to do a fully formal writeup of finalizers. We think it
would add some substantial complications to the base model,
just to handle cases that people really shouldn't care about.
A lot of this is already in appendix C of the draft spec.
* there is a happens-before edge from the constructor to
the finalizer (this is the only thing that is really new)
* synchronizing on an object counts as an active use of
the object that keeps it from being finalized, if
the finalizer may invoke synchronization on the object
* all active uses of an object (accessing a field of the
object, synchronizing on the object, or writing a reference
to an object) count as "reaching" the object from the
thread performing the action.
* The JVM uses some unspecified mechanism for deciding which
objects are reachable from threads
* If an object o1 is reachable, and an element of o1 contains
a non-overwritten reference to an object o2,
then o2 is reachable.
* If an object is unreachable, the finalizer for that object
may be run
So there are two recommended ways of writing finalizers:
* The finalizer only depends on seeing writes performed
in the constructor of that object
* The finalizer using synchronization to ensure that
it is correctly synchronized with all the writes it
needs to see
Any other way is deprecated (not officially, but in practice),
and we won't give detailed semantics for those cases.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:05 EDT