[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