RFR: 8254146: Avoid unnecessary volatile write on new AtomicBoolean(false)
Christoph Dreis
github.com+6304496+dreis2211 at openjdk.java.net
Wed Oct 7 18:21:17 UTC 2020
On Wed, 7 Oct 2020 17:57:49 GMT, DougLea <github.com+2233919+DougLea at openjdk.org> wrote:
>>> I'm a little hesitant about the precedent of checking for 0 in every ctor argument for a volatile field.
>>
>> I'm confused by this if I'm entirely honest @DougLea . Where do we check for 0 in the proposed change?
>
> As in: If unnecessarily writing 0 to a voltaile field in a ctor is expensive enough for a code work-around here, don't
> you think it would be better to teach a compiler to avoid it?
I see what you mean now - thanks! Given that there exists already an empty `AtomicBoolean` constructor that avoids the
volatile write, I didn't see that as a big problem to be honest. Also: The proposed "workaround" doesn't seem to be
overly complicated - personally I find the empty constructor to be the bigger workaround and less explicit.
The same argument applies to initializing volatile fields with their default value, if I'm thinking about it longer. Of
course one would wish that the compiler would be able to avoid it, but there have been examples in the past already
where the explicit volatile write was avoided (e.g. in [JDK-8145680](https://bugs.openjdk.java.net/browse/JDK-8145680)
instead of working on [JDK-8145948](https://bugs.openjdk.java.net/browse/JDK-8145948) for example).
Overall, I think it's a reasonably simple improvement with a good performance gain for relatively little cost, but
after all I'm in your hands when it comes to approving the proposed change.
-------------
PR: https://git.openjdk.java.net/jdk/pull/510
More information about the core-libs-dev
mailing list