On Thu, 15 Oct 2020 12:09:09 GMT, Сергей Цыпанов <[email protected]> wrote:
>>> What do you think? >> >> For `AtomicBoolean`, this optimization piggy-backed on an existing test, >> just rewriting it so that no action is taken >> when none is needed. So it's never a pessimization, and even improves >> bytecode size marginally. So it'll be a marginal >> gain even if the current overhead of writing to a volatile field in a >> constructor is removed/reduced. For >> `AtomicInteger/-Long`, we'd have to add a test that's not there, so we'd >> pessimize non-zero cases by adding some >> bytecode and a branch to remove the overhead. An overhead that can already >> be avoided by calling the empty constructor >> instead. So I think it's questionable to do this. 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. > > @cl4es , @dreis2211 thanks for explanation! > 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. I misphrased somewhat: I think we should try and remove explicit stores of default values to volatile fields in constructors, as suggested by https://bugs.openjdk.java.net/browse/JDK-8145948 I can't think of a way this would break any program (even arguably incorrect ones), and would net us the gains shown in comments here without any point fixes. ------------- PR: https://git.openjdk.java.net/jdk/pull/510
