Hans Boehm wrote:
> 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.
The fact that there is no specification that states what a legal
transformation of Java source statements into Java bytecode is, will
always be a problem. I believe the JMM already relies on the most
obvious/naive interpretation - otherwise we're back to the old problem
of when can the source compiler issue a DUP rather than a GETFIELD for
volatiles.
> 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.
I guess this comes down to how you interpret the spec:
"A reachable object is any object that can be accessed in any
potential continuing computation from any live thread."
I would certainly like to think that the intent here was that an
object that is referenced by a reachable object is itself reachable.
But you can argue that if the continuing computation doesn't access
a.x even though it accesses a, and no other thread can access a, then
a.x is not reachable. This seems far too chaotic for me to
contemplate - I like the idea of the reachability graph of a program
being well defined at any given instant of time, without regard to
what the program might do in the future.
> 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.
I think this should be true without regard for final or volatile.
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:00:42 EDT