RFR: 8254146: Avoid unnecessary volatile write on new AtomicBoolean(false)

Andrew Haley aph at redhat.com
Thu Oct 15 12:41:28 UTC 2020


On 15/10/2020 11:41, Claes Redestad wrote:

> In the short term we could consider a point fix to replace existing
> use of `new AtomicInteger/-Long(0)` with `new
> AtomicInteger/-Long()`, but in the long term we should really try
> and optimize our JITs so that writing to a volatile field in
> constructors can be made cheaper.

I guess it all depends on whether there's a happens-before
relationship between the volatile store to Field X in a constructor
and any subsequent get() of Field X in another thread. Intuitively I
would have thought so, but I can't find any guarantee in the spec.
Nonetheless, I think we'd have little gain by changing this and it
might break (arguably incorrect) programs.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671



More information about the core-libs-dev mailing list