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