> -----Original Message-----
> From: David Holmes [mailto:dholmes@dltech.com.au]
>
> 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.
At least for Jeremy's and Bill's draft spec, that's implicitly answered
by the happens-before constraints, without reference to byte codes.
I would really like to keep it that way.
...
>
> > 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.
>
It's clearly possible to make a case for that, and it may be the
right thing to do. It would make more existing code correct.
My argument for limiting it to volatile and final:
1) It's less likely to interfere with optimization. Optimizing
away a store to a final field is not likely to be a big win, even if
it's otherwise possible. Volatile fields are hopefully rare, and this
is consistent with the intuition that the compiler should not try to
optimize volatile field accesses. If I apply this to all fields,
I suspect it would often be hard to eliminate stores to dead fields,
or to eliminate those fields entirely. (There seems to be some evidence
that eliminating dead fields can be profitable. Cf. Peter F. Sweeney and Frank Tip, A study of dead data members in C++ applications , In Proceedings of the ACM SIGPLAN '98 Conference on Programming Language Design and Implementation (PLDI'98).)
2) It's in some sense a smaller change to the spec.
3) It means something to say than an object is reachable up to a
certain assignment to a volatile field, since it guarantees that
under some circumstances the finalizer can actually see all memory
operations preceding the write, and volatile accesses in the finalizer
have to happen later. I don't have a good intuition for how to
take advantage of the fact that something is reachable up to an
ordinary write.
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