RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]

[Kim Barrett]

On Tue, 20 Oct 2020 16:35:02 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>>> @kimbarrett your reworded text is okay. I think "if it initially had some other referent value" can be dropped.
>>> 
>>> For a `Reference` constructed with a `null` referent, we can clarify in the spec that such reference object will never
>>> get cleared and enqueued. I suggest to file a separate issue to follow up.
>> 
>> I don't think that clause can be dropped, because of explicit clearing (by clear() or enqueue()) rather than by the
>> GC.  If the reference was constructed with a null referent, ref.refersTo(null) cannot tell whether ref.clear() has been
>> called.
>
>> Mandy's comment implied that references with a null referent never get enqueued. Otherwise when would they get
>> enqueued? There would be nothing to trigger it.
> 
> Sorry I should have been clearer.    What I try to say is that `Reference(null)`
> will never be cleared and enqueued by GC since its referent is `null`.
> 
> Kim is right that `Reference(null)` can be explicitly cleared and enqueued
> via `Reference::enqueue`.    `Reference::clear` on such an "empty" reference
> object is essentially a no-op.    Whoever creates an "empty" reference would
> not intend to be cleared.
> 
>> > But the more we discuss this the more I think allowing an initial null referent was a mistake in the first place. :(
>> 
>> I agree, but here we are. Very hard to know what the compatibility impact of changing that would be.
> 
> There are existing use cases depending on `Reference(null)` for example as a special
> instance be an empty reference or the head of a doubly-linked list of references.
> This was discussed two years ago [1].
> 
> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054325.html

David, Mandy, and I discussed the wording in refersTo javadoc and reached a consensus that is reflected in 3a15b6a.

-------------

PR: https://git.openjdk.java.net/jdk/pull/498