My apologies for confusing things further regarding GC not seeing a
reference in a register. That was a misunderstanding on my part. I was
trying to reason how the object may no longer be seen by the GC. Obviously
my thinking here was naive.
Jeremy's post clarifies things.
Dave Detlefs writes:
> The optimization of deciding whether a local variable would be
> accessed in the future? Many do, and it can be an important
> optimization.
No that wasn't what I meant. I understand that assignment to a local that is
never used again results in a dead reference and so the object can be
considered unreachable at that point. Having a locally referenced object
become unreachable prior to the end of the block in which the local exists
is fine.
The problem is the optimisation that considers a locally referenced object
to be unreachable even though that object is still logically being used
after the point at which the optimization makes it unreachable.
> Look, objects are only going to become unreachable early via
> aggressive compiler optimization. A (correct) compiler can only be as
> aggressive as allowed by the semantics and the analysis it does of the
> portion of the program it sees. If the JIT compilation of your
> "someMethod" doesn't inline "useB" to determine whether or not it uses
> its "this" argument, then it must conservatively assume it will, and
> keep "man" alive locally up until the point of the call, after which
> it can let "useB" keep its "this" alive or not, depending on the
> semantics of "useB".
That makes sense. So the optimisation can only occur if inlining occurs (or
a suitable analysis occurs). So to prevent the optimisation we can consider
both the code in the caller and the code in the callee. Hence Hans's sync
block at the end of useB has the same effect as a sync block at the end of
someMethod.
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