> -----Original Message-----
> From: David Holmes [mailto:dholmes@dltech.com.au]
>
> > 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.
I don't think that follows from the spec. I don't see a requirement that
every source level method invocation must be translated to the
corresponding invocation byte code instruction. And certainly a JIT
compiler is free to optimize away dead variables when it translates the
byte code. (Section 12.6.1: "Optimizing transformations can ... reduce
the number of objects that are reachable ...".) And if you really wanted
to go down this route, you would have to ask about memory ordering and
visibility of the 'this' pointer from the thread running the collector.
(E.g. the possible reuse of the 'this' pointer slot you describe below
may appear to the collector to happen earlier.)
>
> 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
> thread."
>
> 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
> unintuitive.
It is safe in the absence of finalization.
...
> 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.
>
I would like to see an explicit statement to that effect.
The other major problem with the current weak reachability spec is the
following:
If objects A and B both have finalizers, A refers to B, and As finalizer
needs to access B, there is no way to ensure that A will be finalized
first. Someone (Guy Steele?) suggested to me
a long time ago that this could be achieved by having As constructor put
B into an always reachable container, and having As finalizer remove it.
I believed that worked for a long time. But it doesn't quite.
The problem again is that B is not guaranteed to
be reachable even if it is in a statically reachable container, since
B will never be accessed through that container.
The "finalizer guardian" idiom in Joshua Bloch's book has the same issue.
There really needs to be some way to ensure that the collector will
view an object as reachable. I believe that the requirement that
- If Object x refers to object y via a final or volatile field and x is reachable, then y must be reachable.
takes care of the issue, probably without any impact on current implementations. (To be pedantic, I'm assuming in the above that loaded classes are reachable. If an object is referenced by a (volatile or final) and static member of a class, it's reachable.)
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:42 EDT