Reachability of an object when a thread is running one of its methods

[Carlo de Wolf]

On 12/05/2012 10:59 AM, Andrew Haley wrote:
> On 12/05/2012 09:00 AM, Carlo de Wolf wrote:
>
>> The example further on shows that an object reference which is on the
>> heap can be optimized away and thus the object can be finalized too
>> early. A reference coming off the stack is allowed to be nullified and
>> it would not trigger finalization. Hence a reference on the stack is a
>> strong one.
> Carlo, you are making this very hard work.  You write things like
>
> "A reference coming off the stack is allowed to be nullified and
> it would not trigger finalization." but without reference to the
> specification.  Does it say anything in the specification to
> support this claim?

JLS 7 12.6.1
"If these optimizations are allowed for references that are stored on 
the heap, then a Java
compiler can detect that the finalizerGuardian field is never read, null 
it out, collect
the object immediately, and call the finalizer early."

In effect, the optimization is allowed for a reference stored on the 
stack, without having the side effect of an early finalize call.

Or am I reading it wrong?
>
>> Probably the real issue is when the stack of the previous frame is
>> cleared, at the start of invoke(virtual) or at the end of
>> invoke(virtual)?
> I'm looking at the example at https://www.ibm.com/developerworks/forums/message.jspa?messageID=14915477
>
> Is that what you're talking about?

Yes, specifically the code I wrote at 
https://www.ibm.com/developerworks/forums/message.jspa?messageID=14915477#14915477. 

>
> You say
>
>> 1. The current frame holds this in variable #0. While technically it
>> is possible to set local variable #0 to null, I find that an
>> extremely dirty action.
> But the specification explicitly allows it.

Yup, which I personally find a dirty action. :-)
Anyway it might warrant an extra warning in spec.
>
> And
>
>> 2. The previous frame is also holding a reference to FinalizeBug (or
>> at least should be ;-) ) in its stack.
> But the specification does not require it to do hold such a reference.
>
> Andrew.
Where does it say that?
Because as you can see it has serious implications for the conceptual 
state of an object.
If it is by omission then either way it should explicitly stated it or 
have an additional warning. (At least that's my opinion. :-) )

Carlo