The more I think about this, the more I'm surprised that finalization is an
issue at all.
I haven't seen the IBM paper. (Is there a public version of it somewhere?)
But it seems to me that between the time an object became garbage and the
time its finalizer is run, you need to run major parts of the garbage
collector. Is there really a danger that that won't involve enough
synchronization between all the threads to force proper ordering? If not,
how do you ensure that the collector sees a sufficiently consistent state to
ensure that it does its job correctly? I don't think any of the collectors
I've seen are in any danger here.
If this reasoning is correct, then we should be able to make very strong
statements about what's visible in finalizers, at essentially no cost.
I agree that nontrivial finalizers need synchronization. But that is true
independent of the memory model issues. If object A references object B,
and there are no other references to B, one of B's methods may still be
running when A is finalized. Thus if As finalizer does anything with B, it
needs to be prepared for concurrent access. And given Java's unordered
finalization, even A's methods can be invoked concurrently from another
finalizer.
Hans
-----Original Message-----
From: Bill Pugh [mailto:pugh@cs.umd.edu]
Sent: Tuesday, March 21, 2000 7:06 PM
To: javaMemoryModel@cs.umd.edu
Subject: JavaMemoryModel: Semantics of finalize
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
-------------------------------
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