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

Mandy Chung mandy.chung at oracle.com
Wed Nov 16 06:11:26 UTC 2016

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

More information about the core-libs-dev mailing list