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

Zoltán Majó zoltan.majo at oracle.com
Wed Nov 16 08:41:26 UTC 2016


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/

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.

Thank you!

Best regards,

Zoltan

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



More information about the core-libs-dev mailing list