Thanks. I think I understand the issue better now. I wasn't thinking about
compiler-based reordering. I'm not sure whether or not the reference count
issues can be dealt with at low cost, but the compiler issues seem more
> A developer could design a system where, if an A object "a" contains
> a reference to a B object "b", then the only reference to "b" is
> through "a", and also guarantee that no threads are working on "b"
> when "a" becomes dead.
That can be tricky. In particular
a = null;
is not safe if a has a finalizer that may call a b method, even if there are
no other threads in the system. The same is true if I call a.bar(), which
calls b.foo() after the last access to a field in a.
> But more to the point, out of 55 finalize methods in Sun's JDK1.3
> rt.jar file, only 1 of them is synchronized. And I expect that is
> about the proportion you would see in other code.
Any idea how many of those are either not externally visible, or safe for
concurrent access by another finalize method?
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