RE: JavaMemoryModel: Finalizer question

From: Boehm, Hans (hans.boehm@hp.com)
Date: Tue Apr 20 2004 - 20:38:26 EDT


> -----Original Message-----
> From: Sylvia Else
> Sent: Tuesday, April 20, 2004 3:44 PM
> To: javamemorymodel-cs.umd.edu
> Subject: Re: JavaMemoryModel: Finalizer question
>
>
> 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.
>
...
> 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?

The answer for ordinary fields is yes, there is a reason not to do it:

It implies that, as far as the compiler is concerned, any potentially final write to
a field of what might be a finalizable object must be treated as volatile,
i.e. it has the same compiler reordering constraints as a volatile,
but the associated hardware barrier (if any) is not needed. Since
finalizers can be added by subclasses, I suspect this potentially affects
a lot of writes.

My guess is that this would require significant repairs to most JVMs,
and it might involve significant performance costs, though I'm less sure
about that.

More significantly, I'm not sure it solves a major problem, for the
reasons I pointed out in my last message. The writes we care about in
a finalizer are rarely to the finalizable object. It's about to go
away. The important state is elsewehere.

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