I agree with Sylvia's concern.
Does this caveat really buy you anything?
To eliminate redundant synchronization, you have to be able to prove
that the object doesn't synchronize in the finalizer. In 99.9%
of the cases the compiler will prove that there is no synchronization
in the finalizer by proving that it only has the trivial one.
But in that case (and assuming it has no weak references, which
would presumably show up as an escaping reference), I don't see what would
prevent the synchronization elimination even without the caveat.
Finalization got into this because we have to say something about
visibility of writes to the finalizer, and finalizers are another way
of creating concurrency. Some of us argued that there was no real way
to do this without making them usable in the process. I think that
all the variants we are discussing are at least minimally usable,
though the pre-JSR133 version is not. I also believe that Java needs
a usable finalization (and/or weak reference) mechanism, even though
it should be rarely used.
I don't believe that keeping "this" reachable during method invocation
should be any different from ensuring reachability of any other parameter.
I think we mostly agree that doing so would simplify the programming model
for the rare user of finalization at significant performance cost for
everyone. Hence we didn't take this route. But there is clearly a
On Thu, 22 Apr 2004, Sylvia Else wrote:
> At 11:49 AM 21/04/2004 -0400, Bill Pugh wrote:
> > * synchronizing on an object counts as an active use of
> > the object that keeps it from being finalized, if
> > the finalizer may invoke synchronization on the object
> I'm unhappy about the caveat "if the finalizer make invoke synchronization
> on the object."
> I understand that the motivation is to maximise the possibilities of
> removing redundant synchronization, but the caveat impinges on reachability
> for the purposes of the reference classes WeakReference, etc.
> I've raises the issue of these classes in the context of finalization
> discussions before, but my comments have been systematically ignored.
> It might be felt that his matter is outside the scope of a new Java memory
> model, but I'm not really sure how finalization got in either.
> JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
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