> There is absolutely no guarantee that while an object's
> method is running the object is reachable, or that
> reference to it is on the call stack.
Okay - now I understand the problem.
The specification for the different invocation bytecodes explicitly
require that objectref be on the stack. So every invocation logically
starts with the 'this' pointer available in local variable zero and
the object is reachable.
The JLS Section 12.6.1 states "A reachable object is any object that
can be accessed in any potential continuing computation from any live
The system might determine that the 'this' pointer is dead and remove
that reference allowing GC to finalize and reclaim the object while
the method is executing. However, if the local reference was dead then
there can't be any use of that object by the thread that is still
executing it's method - and so it *seems* safe, even if a little
On the other hand, if the local reference was not dead then the
optimisation is invalid and its a VM bug. If a VM "optimises" things
by placing the 'this' pointer in a register and not considering that
it is a live reference for GC purposes, thus allowing it to be
reclaimed while being used, then that is also a bug in the VM/GC.
So I can see that indeed an object can 'disappear' while a method is
executing upon it - but only if the object will in fact never be
So in the context of your original example: yes the finalizer could
have cleared the static data associated with the object x, before the
execution of x.foo gets to read it. It is, as you stated, a data
race - though a subtle one.
On the issue of synchronization I agree with you. It is not clearly
stated, though I think it can be inferred, that an object upon which
the monitor lock is held must be reachable - and hence is reachable at
the time the lock is released.
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:42 EDT