At 01:05 PM 4/1/2003, Boehm, Hans wrote:
> > From: Jerry Schwarz [mailto:jerry.schwarz@oracle.com]
> > In short, I do not believe that unless we limit what constitutes an
> > allowable optimization beyond its normal meaning (doesn't
> > change the effect
> > of the program) that we can ever guarantee that the output of
> > the program
> > is not
> >
> > finalizer called
> > Say what you want
> >
>Do we agree that requiring an object to be reachable until the last time
>its lock is released is a sufficient limit on the optimizer?
Yes, provided that it is expressed in terms of when the lock is released in
terms of the original java source. The system could still optimize away
locks/unlocks, it just needs to be sure that the object is reachable at the
nominal unlock. In particular to reuse the example I gave earlier
f() {
X x = new X();
synchronized ( x ) {
// x is never stored somewhere another thread could see it.
...
}
}
The lock/unlock pair can be eliminated, but the finalizer can't be called
until all the updates to x have been done.
But I would really prefer a construct where I wouldn't have to depend on
the optimizer getting rid of the relatively expensive lock/unlock operation.
>Thinking about this some more, I think it also has the beneficial effect
>that we can delete the "Guarantees for finalizers" section from the memory
>model specification.
>
>The right programming model for finalizers is clearly to synchronize both
>the finalizer and any other method that might be the last method call on
>an object. As Jerry has also pointed out, anything else is virtually
>guaranteed to be broken. This proposal guarantees that methodology to be
>correct, while making it clearer that it is essentially required.
>
>If you use this methodology, any updates to the object are automatically
>visible in the finalizer, due to the synchronization. Hence, there should
>not be a real need to specifically say anything about finalizers in the
>memory model spec.
>
>Thus I believe that including a reachability guarantee for synchronization
>would reduce the length of the overall spec, which would clearly be a good
>thing.
>
>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:43 EDT