RFR: 8264032: Improve thread safety of Runtime.version()

liach github.com+7806504+liach at openjdk.java.net
Tue Mar 23 12:25:55 UTC 2021


On Tue, 23 Feb 2021 16:46:06 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> There are 2 separate reads of fields. First can return non-null value, while second still can get null

Can this really happen? If this `version` field has been updated, its value is definitely no longer `null`. And before the second field read the field is always set to a non-null value on the current thread. I fail to understand why the second read can still yield a null given the fact that the current thread has updated it to a non-null value and other threads may have updated it to a non-null value.

>> src/java.base/share/classes/java/lang/Runtime.java line 824:
>> 
>>> 822:                     VersionProps.pre(), VersionProps.build(),
>>> 823:                     VersionProps.optional());
>>> 824:             version = v;
>> 
>> Can't this just be `return version = new Version(...` than reassigning to a local variable for no good?
>
> It's matter of style. I've seen both styles are acceptable in JDK codebase. I personally prefer placing assigning each variable into separate lines.

Doesn't using `return version = new Version(...` allow one local variable to be effectively final and save two aload/astore opcodes? Guess jvm optimizes it

-------------

PR: https://git.openjdk.java.net/jdk/pull/2691


More information about the core-libs-dev mailing list