I think we are still misunderstanding each other. Or perhaps we are
understanding the spec differently.
Assume UseB synchronizes on this, i.e. man at the end of its
execution. The object man must be considered reachable at least up to
that point, since the synchronization itself is considered an access to
the object. And all accesses to shared memory in someMethod happen before
that. Hence the finalizer must see the state from after the execution of
useB.
In my mind, it is not legal for the finalizer to execute at the first two
points you suggest. The object cannot be finalized until the last active
use. And the synchronization is an active use.
On rereading, I'm a little confused by the formal statement in the 3rd
edition of the JLS, which is presuambly identical to the JSR133 document.
The formal spec mentions a read as an active use, but the text doesn't. I
somehow thought we had decided not to do that. I'm not sure what
implications that has. If I write to some other place outside the object,
and then read a final field in the object, must the write be visible to
the finalizer? Even if the value of the final field is a compile-time
constant? I think it doesn't. But I'm unsure what implications this has
on either the implementor or user.
Hans
On Mon, 2 May 2005, David Holmes wrote:
> Hans,
>
> > My model was that in the ResourceManager code, both useA and useB
> > end with something that enforces reachability of "this", i.e. the
> > ResourceManager.
>
> You have missed my point. It is not sufficient that the resource manager be
> reachable during execution of its own methods useA and useB, it must also be
> seen to be reachable during executing of the client code someMethod,
> otherwise the resource manager could be finalized in between the calls to
> the resource manager methods:
>
> void someMethod() {
> ResourceManager man = new ResourceManager();
> // man could be finalized here
> int result1 = man.useA();
> // or here
> int result2 = man.useB();
> // or here
> }
>
> Unless the system treats useA/useB as inlined and can see those internal
> sync blocks then I don't see how those internal sync blocks will help. Now
> if they *were* inlined then sure I can see that a sync block at the end of
> useB would be indistinguishable from a sync block at the end of someMethod.
> But is that the way it is supposed to work? Is the system supposed to be
> able to see inside those called methods to determine reachability?
>
> This seems horrednously complicated, both from the programmers perspective
> and the systems. What kind of analysis would the system have to do to
> determine that an object can be considered unreachable when only referenced
> by a local? Why would they bother doing that analysis?
>
> Cheers,
> David Holmes
>
>
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:10 EDT