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

[Mandy Chung]

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

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

Mandy
[1] The Java Programming Language, Fourth Edition, section 17.5.4