OK, we've reviewed the stuff on references.
I think most of this stuff can go into the java.lang.ref JavaDoc rather
than the jsr133 spec. After all, references are not mentioned in the
JLS.
Within the Reference class, there should be an hb edge
from creation of the Reference or call to clear()
to each call to get() and to the reference being dequeued from a
ReferenceQueue
Essentially, this would be handled by making the referent field
volatile. Right now,
if you have a loop that spins on a Reference, waiting for it to be
cleared, the compiler
can hoist the read of the referent field out of the loop. Making it
volatile would
(essentially) prevent that. Although this is a dubious code idiom,
there are similar
idioms that are not so dubious.
As far as reachability, I'd rather not duplicate the text in the
JavaDoc, nor
do I want to complicate the java.lang.ref JavaDoc by bringing into it
all
the complications we have in the formal reachibility definition.
I think if we just say that the reachability decision points are also
the points
at which references can be cleared or enqueued, according to the rules
declared
in the java.lang.ref JavaDoc, using the rules described here for when
an object
is reachable. I think that will cover our bases.
Is that acceptable to most everyone?
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:07 EDT