RE: JavaMemoryModel: Semantics of finalize

From: Bill Pugh (
Date: Wed Mar 22 2000 - 16:43:40 EST

>If this reasoning is correct, then we should be able to make very strong
>statements about what's visible in finalizers, at essentially no cost.

No. Consider
class A {
static boolean flag = false;
static A a = new A();

static void test() {
   flag = true;
   a = null;

protected finalize() {
   boolean b = flag;
   if (!b) System.out.println("This is strange!");
   System.out.println("This is normal");



Question: Is the finalize method guaranteed to see the write to flag? If so,
        then you can't reorder two writes if the second one might
make an object

>I agree that nontrivial finalizers need synchronization. But that is true
>independent of the memory model issues. If object A references object B,
>and there are no other references to B, one of B's methods may still be
>running when A is finalized. Thus if As finalizer does anything with B, it
>needs to be prepared for concurrent access. And given Java's unordered
>finalization, even A's methods can be invoked concurrently from another

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.

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.

JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:24 EDT