> On Feb 4, 2016, at 7:52 PM, Mandy Chung <mandy.ch...@oracle.com> wrote: > > >> On Feb 4, 2016, at 2:37 PM, Hans Boehm <hbo...@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 >> observations: >> >> 1) I don't know of any way to write correct code that is oblivious to this >> difference. >> 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 referent.)
