JDK-8052260 (Reference.isEnqueued()) Discussion
kim.barrett at oracle.com
Mon Feb 8 21:58:20 UTC 2016
> On Feb 4, 2016, at 7:52 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>> On Feb 4, 2016, at 2:37 PM, Hans Boehm <hboehm at google.com> wrote:
>> The discussion at https://bugs.openjdk.java.net/browse/JDK-8052260
>> correctly points out that the spec implies that this should be true if the
>> reference has ever been enqueued, while the implementation returns false
>> once it has been removed from the queue. The current proposal is to change
>> the spec.
> The spec needs clarification (not a spec change and no behavioral change).
>> I'd like to make a different proposal, based on the following
>> 1) I don't know of any way to write correct code that is oblivious to this
>> 2) AFAIK, this has been broken in this way for a long time, possibly from
>> the beginning, i.e. for more than 15 years(?). The bug is dated 2014.
>> Apparently nobody noticed for a long time.
> AFAIK nothing is broken.
What's broken is that the implementation for isEnqueued does not match
its specification, as discussed in the original report for
JDK-8052260. That is, I think the present wording is pretty clear,
and is not consistent with the present implementation.
So I disagree with the classification of the proposed wording change
as a "clarification". Rather, I would describe it as a *change* to
the specification to match the implementation. Alternatively, one
could address the problem by fixing the implementation to match the
specification; the bug report suggests a possible method for doing so.
I think the implemented behavior is pretty nearly useless, and also
confusing, which agrees with Hans Boehm's finding that none of the
uses he examined were correct under that behavior. I think the
specified behavior is marginally more useful than the implemented
behavior. So I would prefer fixing the implementation rather than
changing the specification. OTOH, I don't think this function has
very much real utility, and don't have any objection to seeing it
removed (after any required deprecation period).
There may be value to having a new predicate function in this area, to
test whether a reference has been cleared or has a null referent or
some such. Now that we're clearing phantom references too
(JDK-8071507), such an operation would be useful for them too, and
would remove any specialness for phantom references with null queues.
But that can be the subject of a separate RFE. (Note that there may
be some trickiness to the implementation of such an operation, due to
some GCs needing read barriers for referent accesses. For example,
when using G1, the obvious implementation of comparing the referent
field's value to null could unnecessarily extend the lifetime of the
More information about the core-libs-dev