At present we specify that the finalizer will see all writes which were
made up to the point at which the object was declared finalizable. One of
the reasons for that choice was that it costs nothing in current
implementations and prevents future VM implementations from making
unsynchronized finalizers even less useful than they are at present. The
point here is that the garbage collection thread must be guranteed to see
all writes from all threads at the point at which it declares an object
finalizable. If that were not true then a pending, but unobserved, write
could be a reference to the object heading for a reachable field in some
other object. The only question is: does the GC thread pass on the
visibility of those writes to the thread running the finalizer ? At
present all implementations do as far as I'm aware since they simply queue
the references under a monitor at negligable cost. What we're doing by
insisting that the finalizer sees the last write is simply to prevent
future VM implementors using some other mechanism which fails to pass on
the write visibility to the finalizer thread. It's very hard to see what
they'd actually do since of course the finalizer thread is one of the ones
that the GC thread must observe the writes from. The net is that the
guarantee costs nothing, is already true of all VMs and MAY be of use in
SOME situations; particularly simple ones in which the developer is writing
code which is completely single thread except for the use of finalizers.
Going back to the original finalizer example this says that both r1 and r4
will be guaranteed to see -1. The one that seems most important is r1
since I think any other value would be a big surprise to most developers
and I really think that an important goal of the memory model is to
minimise surprises.
Martin Trotter
-------------------------------
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