[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