[PATCH] Drop explicit zeroing at instantiation of Atomic* objects

Сергей Цыпанов sergei.tsypanov at yandex.ru
Wed Sep 30 20:30:20 UTC 2020


Hello,

often objects of atomic types e.g. AtomicInteger are explicitly zeroed at initialization,
which is redundant and slower than relying on default values (zeros):

@State(Scope.Thread)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@BenchmarkMode(value = Mode.AverageTime)
public class AtomicBenchmark {
 
 @Benchmark
  public Object defaultValue() {
    return new AtomicInteger();
  }

  @Benchmark
  public Object explicitValue() {
    return new AtomicInteger(0);
  }
}

Semantically both new AtomicInteger() and new AtomicInteger(0) are the same,
but explicitValue() is much slower:

Benchmark                      Mode  Cnt   Score   Error  Units
AtomicBenchmark.defaultValue   avgt   30   4.778 ± 0.403  ns/op
AtomicBenchmark.explicitValue  avgt   30  11.846 ± 0.273  ns/op

The reason is assignment to volatile fields which is not necessary [1].

Previously there were similar clean-up issues, e.g. [2], which in its nutshell
is about the same.

If this change is relevant then I'd like someone to file an issue
to let me create a proper PR for it.

Patch is attached.

Regards,
Sergey Tsypanov


1. http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html
2. https://bugs.openjdk.java.net/browse/JDK-8035284
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Drop_explicit_zeroing.patch
Type: text/x-diff
Size: 9750 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20200930/a5eab1cb/Drop_explicit_zeroing-0001.patch>


More information about the core-libs-dev mailing list