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

[David Holmes]

On 20/10/2020 5:01 pm, Kim Barrett wrote:
>> On Oct 20, 2020, at 2:09 AM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> On 20/10/2020 3:26 pm, Kim Barrett wrote:
>>> On Tue, 20 Oct 2020 03:25:45 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.
>>
>> I think that can be addressed by considering a Reference created with a null referent to be immediately cleared.
> 
> I think if it’s treated as immediately cleared then it should also be immediately enqueued.  But immediate

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.

David
-----

> enqueue has problems; it can’t be done by the Reference constructor because the derived constructors
> have not yet completed, and exposing the possibly incompletely constructed object to the queue processor
> is problematic.  And if it can’t be done by the constructor, it’s not clear who would do it.
> 
>> 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.
>