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
