JavaMemoryModel: Semantics of finalize

From: Bill Pugh (pugh@cs.umd.edu)
Date: Tue Mar 21 2000 - 22:06:17 EST


Just to go over what was discussed earlier...

Losing the last reference to an object is an asynchronous signal to
another thread to invoke the finalizer. Thus, there is substantial
question as to which writes the finalizer is guaranteed to see.

I propose that the finalizer be guaranteed to see all writes to the
object being finalized, but nothing else. If the object being
finalized contains a field p that contains reference to an array,
then the finalizer is guaranteed to see (one of) the last writes to
p, but as absolutely no guarantees about seeing writes to the array p
references.

For anything but fairly trivial finalizers, this will require the use
of synchronization.

A possible extension: we might be able to also guarantee that the
finalizer would see all of the writes done during construction of the
object being finalized.

If you have a garbage collector such as in the PLDI2000 paper:

Java without the Coffee Breaks: A Nonintrusive Multiprocessor Garbage Collector
David Bacon (IBM T. J. Watson Research Center), Dick Attanasio (IBM
T. J. Watson Research Center), Han Lee (University of Colorado,
Boulder) and Stephen Smith (IBM T. J. Watson Research Center)

then what this means is that when an object with a finalizer becomes
garbage, you just put in on a list. From time to time, if that list
is non-empty, you need to perform a global memory barrier (involving
all processors). After that barrier, all objects on the list become
eligible for finalization.

-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel



This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:24 EDT