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

[Peter Levart]

Hi Zoltan, Mandy,

On 11/16/2016 09:41 AM, Zoltán Majó wrote:
> Hi Mandy,
>
>
> On 11/16/2016 07:11 AM, Mandy Chung wrote:
>>> On Nov 15, 2016, at 4:41 AM, Zoltán Majó <zoltan.majo at oracle.com> 
>>> wrote:
>>>
>>>
>>> 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).
>>>
>> When a reference becomes unreachable (not by examining the source 
>> code but the actual state of the VM at runtime), it will never be 
>> enqueued.
>
> I also like that wording, thank you!
>
>>
>>> 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.
>>
>> That’s fair.
>>
>> What I’m looking for is something like this [1]:
>>
>> Reachability is not determined by the statements in your source code 
>> but by the actual state of the virtual machine at runtime.
>
> OK, I see now -- thank you for explaining.
>
> Here is a new webrev (webrev.03) that includes what you suggested:
>
> http://cr.openjdk.java.net/~zmajo/8169000/webrev.03/

"If a registered reference ceases to be strongly reachable itself (not 
by examining the source code but by looking at the actual state of the 
VM at runtime), it will never be enqueued."

I think this is wrong wording. A Reference object may cease to be 
strongly reachable for some time (even by looking at the actual state of 
the VM at runtime) and then regain strong reachability and then be 
enqueued. If during the period that a Reference object is not strongly 
reachable (even by looking at the actual state of the VM at runtime), GC 
is not run, the Reference object will not be discovered as not being 
strongly reachable and VM will not clear any Soft or Weak references 
having the Reference object as a referent and consequently the program 
will be able to regain strong reachability to it.

>
> We could go either with this webrev or with the previous one 
> (webrev.02) that changes "will never be enqueued" to "may never be 
> enqueued".
>
> http://cr.openjdk.java.net/~zmajo/8169000/webrev.02/
>
> I'm not sure which webrev is the better option.

"If a registered reference ceases to be strongly reachable itself, then 
it may never be enqueued."

I think this is a better wording. We can even (but not need to) say the 
following:

"If a registered reference ceases to be strongly reachable itself by 
examining the source code, then it may never be enqueued."

...and the statement will still be correct. By: "an object ceases to be 
strongly reachable by examining the source code", I mean: "the earliest 
point possible in program where no reference variable through which the 
object can be reached directly or indirectly (not traversing any 
Reference's referent) can be dereferenced any more". For example:

void m() {
     ...
     Object o = new Object();
     // <- this is the earliest point in program where the sole variable 
'o' through which the Object could be reached, can't be dereferenced any 
more.
     ...
     ...
     ...
    // ... (there's no mentioning of 'o' in the rest of the method)
}

Regards, Peter

>
> Thank you!
>
> Best regards,
>
>
> Zoltan
>
>> Mandy
>> [1] The Java Programming Language, Fourth Edition, section 17.5.4
>>
>