[PATCH] remove redundant initialization of volatile fields with default values
Сергей Цыпанов
sergei.tsypanov at yandex.ru
Fri Jun 19 04:57:25 UTC 2020
Hello,
while investigating an issue I've found out that assignment of default value to volatile fields slows down object instantiation.
Consider the benchmark:
@State(Scope.Thread)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@BenchmarkMode(value = Mode.AverageTime)
@Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
public class VolatileFieldBenchmark {
@Benchmark
public Object explicitInit() {
return new ExplicitInit();
}
@Benchmark
public Object noInit() {
return new NoInit();
}
private static class ExplicitInit {
private volatile boolean field = false;
}
private static class NoInit {
private volatile boolean field;
}
}
This gives the following results as of my machine:
Benchmark Mode Cnt Score Error Units
VolatileFieldBenchmark.explicitInit avgt 40 11.087 ± 0.140 ns/op
VolatileFieldBenchmark.noInit avgt 40 3.367 ± 0.131 ns/op
I've looked into source code of java.base and found out several cases where the default value is assigned to volatile field.
Getting rid of such assignements demonstates improvement as of object instantiation, e.g. javax.security.auth.Subject:
Mode Cnt Score Error Units
before avgt 40 35.933 ± 2.647 ns/op
after avgt 40 30.817 ± 2.384 ns/op
As of testing tier1 and tier2 are both ok after the changes.
Best regards,
Sergey Tsypanov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: volatile.patch
Type: text/x-diff
Size: 6253 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20200619/51b9dd83/volatile.patch>
More information about the core-libs-dev
mailing list