> From: Bill Pugh
> The point is that most finalizers are not synchronized.
>
> So declaring them all to be broken is a big step we'd like to avoid.
But I would guess something like 80% of those were always pretty clearly broken,
and will remain so until someone goes in and fixes them.
I think that in the large majority of cases, the last method to
run before the finalizer does something like:
1) Read some sort of handle from the finalizable object.
This will read an ordinary or final field of the object.
2) Use the handle to look up a corresponding entry in a global data
structure, possibly locking the global data structure, but not the
object. (The global data structure may be one that represents a
file in the OS kernel, i.e. it may not be in the user process.)
The global data structure is likely to be modified, the object probably
won't be. (Having the object itself modified might help,
if it's done after the global data structure update, and that's locked.)
Neither one ensures reachability of the object. And (2) will usually
fail if the object was already finalized, since that tends to clean up the corresponding
entry in the global data structure. Such methods need to either lock or
store something into a volatile field of the object.
(Storing into a nonvolatile field of the object while holding the
lock on the global data structure is probably also OK, at least
with the revised rules. But it's also idiomatic.)
>
> So I think we need to ensure that r1 will be equal to -1.
I agree that it's an improvement. But it's no silver bullet.
I think it'll "fix" a very small percentage of the code.
Hans
-------------------------------
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