I agree with Dave Detlefs' comments about finalization. (And add that it
may not be hard to deal with exceptions in finalizers, in the sense that
one wraps the call to the finalization code in an exception handler that
catches anything and then ignores the exception; if this is not
specifically in Java, it doesn't matter -- it can be an implementation
level concept.)
I am wondering whether the Reference classes are more problematic in some
sense in that they involve a clear distinction between a before-gc and an
after-gc epoch (where by gc I mean the detection of non-reachability of the
Reference object's referent).
Or maybe the underlying problem is the same: Whether a gc and then code
after it can somehow "miss" some writes to an object that becomes
unreachable, and thus be "confused" in some sense.
I can say that the Sapphire concurrent collector assumes (in some sense) no
data races on non-volatile fields (i.e., in the new copy of an object, if
there is a data race, the value of a field involved in a race may be
unpredictable (but not out of thin air) and different from the old copy's
value). For _volatile_ fields, we use suitably strong synchronization as to
guarantee that the sequence of values of a field remains well defined in a
global sense, essentially by atomically moving attention from the old copy
to the new copy. (Our approach would be unpleasant for C, precisely because
one would have to use our "volatiles" approach for _all_ fields, and our
treatment of volatiles is rather higher cost than our treatment of ordinary
fields. In essence, we gain an advantage by leaning on Java's
synchronization.)
Is this relevant to the discussion? I'm not sure. Maybe the gc's inherent
use of memory ordering operations on object header fields (and on the user
visible fields) is more relevant?
-- Eliot
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:06 EDT