David --
> > 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.
I for one, am continuing to miss your 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
> }
I guess I would say "of course," with some puzzlement. We're talking
about the definition of reachable here, and you seem to have some idea
about I don't understand. It seem obvious (to me, at least, and I
suspect to Hans) that the ResourceManager allocated at the second line
must remain reachable at least until the invocation of "useB" --
a stack frame must have a live local reference to an object in order
to invoke a non-static (non-inlined) method on it. So I don't see why
you say that "man can be finalized here" or at the first "or here".
The second one, in the last line, sure -- "man" is a dead local
variable after this line, and it might be the last reference to the
ResourceManager.
The whole issue Hans is concerned with (which he referred to "by
reference" in this email exchange, without (re-)spelling out the
details, concerns situations where "this" becomes a dead local
variable within methods like "useB", so that no references are live
anywhere. For example, useB might have read an integer out of it's
"this", that's an index into some static native array, after which
"this" becomes dead. This allows the finalizer to run, concurrently
with the tail of "useB" -- the finalizer races to delete "man's" entry
from the static native array.
So Hans is searching for a way, if you had identified that a method
like useB might be in this situation, to guarantee in Java code that
the "this" of useB stays live until the end of the method, keeping a
finalizer from running.
I hope this is helpful (and accurate!)
-- ============================================================================= Dave Detlefs http://www.sunlabs.com/people/detlefs/ Sun Microsystems Laboratories david.detlefs@sun.com 1 Network Drive, Burlington, MA 01803-0902 (781)-442-0841------------------------------- 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