JDK-8052260 (Reference.isEnqueued()) Discussion
mandy.chung at oracle.com
Fri Feb 5 00:52:27 UTC 2016
> 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.
> 3) I don't know of any useful correct code that uses the function as
> implemented. The implemented and proposed semantics seem to be inherently
> racey, at least if the associated queue is processed asynchronously.
> Martin Buchholz suggested debugging statistics as a possible use. That
> seems to be the best answer to date, but it still seems to me that a heap
> profile would generally serve better in such cases.
> 4) I've looked at as many clients as I could find. The number is in the
> single digits. I don't believe any of them are correct with the current
> implementation. The majority misuses isEnqueued() on References without an
> associated queue as a test to see if the reference has been cleared.
Ah, I see. Hmm.. should code review catch this?
The spec is clear on this point though:
If this reference object was not registered with a queue when it was created, then this method will always return false.
> In one case this introduced a potentially serious bug; in other cases it just
> slowed down the code.
> My conclusion is that this call currently only serves to inject bugs and
> slowdowns into code written by unwary users. I suggest deprecating it.
Fair point while deprecation may not be the right answer to address “mis-reading” of the spec. On the other hand, this method does not seem to be useful. I have included your comment in the JBS issue to consider.
More information about the core-libs-dev