JDK-8052260 (Reference.isEnqueued()) Discussion

[Hans Boehm]

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.  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.
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.  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.