On Thu, 15 Oct 2020 09:17: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. ------------- PR: https://git.openjdk.java.net/jdk/pull/510
