[9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package

Peter Levart peter.levart at gmail.com
Thu Nov 17 00:00:31 UTC 2016


Hi David,


On 11/17/2016 12:35 AM, David Holmes wrote:
>> Why are we insisting in specifying when it is guaranteed for a Reference
>> object to *not* be enqueued. This is not very helpful.
>
> I disagree. The whole point of the statement was to make it clear that 
> for a referent to be enqueued the referee reference type must itself 
> remain reachable. The problem with the statement was that it could be 
> misconstrued as indicating when a referent _must_ not be enqueued.

The original text is correct: "If a registered reference becomes 
unreachable itself, then it will never be enqueued".

And we must actually read it as "then the reference  _must_ not be 
enququed".

The transitioning of reachability from unreachable to strongly reachable 
is not allowed. If a registered reference becomes unreachable then it 
_must_ not be enqueued as enqueueing would transition it to strongly 
reachable from unreachable and break the spec.

Regards, Peter

>> A more helpful information for a programmer would be to specify when a
>> Reference object is guaranteed to *be* enqueued. Guarantee is given only
>> if the Reference object is kept strongly reachable. If it ceases to be
>> strongly reachable, it may never be enqueued, but it is not guaranteed
>> that it will not be enqueued either.
>>
>> So this is still my favorite:
>>
>> "If a registered reference ceases to be strongly reachable for any
>> period of time, it may become unreachable and never be enqueued. In
>> order to guarantee for a registered reference to be enqueued, it must be
>> kept strongly reachable at all times."
>
> That seems redundant to me. Given the reachability definitions it 
> reduces to "If a registered reference becomes unreachable it may never 
> be enqueued."
>
> David 



More information about the core-libs-dev mailing list