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
serious.
> 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.b.foo();
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?
Hans
-------------------------------
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