Re: JavaMemoryModel: Finalizer question

From: Sylvia Else (
Date: Tue Apr 20 2004 - 18:44:23 EDT

At 02:40 PM 20/04/2004 -0400, Bill Pugh wrote:
>>>class A {
>>> static A g;
>>> long x;
>>> protected void finalize() {
>>> g = this;
>>> long r1 = x;
>>> // ...
>>> }
>>> }
>>> Thread 1:
>>> A r2 = new A();
>>> r2.x = 1;
>>> r2.x = -1;
>>> Thread 2:
>>> do {
>>> r3 = A.g;
>>> } while (r3 == null);
>>> r4 = r3.x;
>So I think we need to ensure that r1 will be equal to -1.

I certainly agree with that. To my mind, it would be a strange outcome
indeed if a finalizer doesn't get to see the final state of the object.

>What about r4? I'm not sure. If A.g was volatile, I think we
>would need to ensure that r4 is -1. After all, if the finalizer
>thread is guaranteed to see -1, and the finalizer thread passes
>the object to another thread in some correctly synchronized
>way, then that other thread should also see -1 for o.x.
>But what if A.g is non-volatile. Perhaps it shouldn't be guaranteed,
>although unfortunately that will complicate the semantics.

At this point you lose me. Maybe I'm looking at this from a different
perspective. Given the need to have r1 = -1, I've rather taken the view
that we need a happens-before edge from each non-finalizer write of an
object to the first memory access in the object's finalizer. Is there any
reason not to do this?

If we have those edges, and A.g is volatile, then r4 is -1 by the normal
rules. If A.g is not volatile, then there is no guarantee.

 From what you've said it appears that your current thinking is that r4 =
-1 would be guaranteed as the model is currently envisaged, even for
non-volatile A.g. Wouldn't this be a big ask for the implementation? If you
modify the example to put the code that sets A.g into a different class,
then at the point where the code for Thread 2's code is generated, the JVM
may not even have loaded the class that stores A.g, let alone realise that
the store is performed from a finalizer.


JavaMemoryModel mailing list -

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