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

[Zoltán Majó]

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.)

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