[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