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

[David Holmes]

Hi Zoltan,

First, I'm okay with latest webrev.

Second, I don't want to confuse things but need to correct one thing ...

On 15/11/2016 10:41 PM, Zoltán Majó wrote:
> Hi Mandy,
>
>
> thank you for looking at this! Please find more details below.
>
> On 11/15/2016 02:51 AM, Mandy Chung wrote:
>>> On Nov 14, 2016, at 6:28 AM, Zoltán Majó <zoltan.majo at oracle.com> wrote:
>>>
>>> Here is the updated webrev with the updated text:
>>>
>>> http://cr.openjdk.java.net/~zmajo/8169000/webrev.01/
>>>
>> This spec uses “unreachable” to refer to when GC detects as
>> unreachable. I think the current spec is correct.
>>
>> What about this suggested clarification?
>>
>> diff --git
>> a/src/java.base/share/classes/java/lang/ref/package-info.java
>> b/src/java.base/share/classes/java/lang/ref/package-info.java
>> --- a/src/java.base/share/classes/java/lang/ref/package-info.java
>> +++ b/src/java.base/share/classes/java/lang/ref/package-info.java
>> @@ -77,8 +77,12 @@
>>    * references that are registered with it.  If a registered reference
>>    * becomes unreachable itself, then it will never be enqueued.  It is
>>    * the responsibility of the program using reference objects to ensure
>> - * that the objects remain reachable for as long as the program is
>> - * interested in their referents.
>> + * that the objects remain strongly reachable for as long as the program
>> + * is interested in their referents.
>> + *
>> + * <p>
>> + * A Java virtual machine may implement optimization that could
>> + * affects when objects become unreachable.
>>    *
>>    * <p> While some programs will choose to dedicate a thread to
>>    * removing reference objects from one or more queues and processing
>
> I think the sentence in webrev.01
>
> (1) "If a registered referenceceases to be strongly reachable itself,
> then it may never be enqueued."
>
> is sufficient. I think we want to make a statement only about what
> happens when a reference ceases to be strongly reachable (i.e., that in
> that case we can't make a statement about that reference being enqueued
> or not).
>
> The sentence you suggested
>
> (2) "A Java virtual machine may implement optimization that could
> affects when objects become unreachable."
>
> adds too much ambiguity as it leaves room for speculation about what
> "optimization" might be.
>
> For example, statement (2) can be possibly (mis-)read as the JVM making
> references unreachable *earlier* than what a programmer may think --
> based on the source code.(That is clearly not the case: References are
> available at least until the latest program point where they are used,
> otherwise the program would encounter an error.)

Actually it can make references unreachable earlier than may be 
expected. The wording Mandy suggested comes from the JLS itself - see 
12.6.1. (Though I agree it isn't the right disclaimer for the current 
situation - where the interpreter keeps the reference reachable longer 
than naively expected).

David
-----

> It's indeed a JVM "optimization" keep references alive *longer* than it
> seems to be from the source code. But (1) already encapsulates that
> without referring to JVM optimizations explicitly.
>
>> [...]
>>
>>
>> Making it clear “strongly reachable” is a good suggestion.  I don’t
>> see word-smithing is needed in the original sentence; hence my above
>> suggested change only adds the word “strongly” in this sentence.
>
> I agree.
>
> Here is the updated webrev:
>
> http://cr.openjdk.java.net/~zmajo/8169000/webrev.02/
>
> Thank you!
>
> Best regards,
>
>
> Zoltan
>
>>
>> Mandy
>