JMH 1.27

[Aleksey Shipilev]

Hi,

JMH 1.27 is released and available at Maven Central.

It comes with the following features and bugfixes:

  *) JMH experimentally supports compiler-assisted Blackholes from OpenJDK 16. They are currently 
disabled by default, so old behavior should be intact. It would be turned by default some time 
later, after JDK 16 stabilizes enough. The runner would tell you how to enable the compiler-assisted 
blackholes when it detects JDK 16 (something like -Djmh.blackhole.mode=COMPILER, but see the JMH 
output for the precise command).
    https://bugs.openjdk.java.net/browse/JDK-8252505
    https://bugs.openjdk.java.net/browse/CODETOOLS-7902762

  It requires considerably fresh JDK 16 EA build. These builds were tested to work:
    https://builds.shipilev.net/openjdk-jdk/

  Please test compiler-assisted Blackholes on your examples, and see if those produce the results 
you want! There is still time to get it fixed for JDK 16 if there are VM troubles, and, of course, 
fix the JMH if problems arise.

  *) "perfasm" profiler used to break when you supplied event modifiers to it, e.g. with -prof 
perfasm:events=cycles:ppp. This was discovered by Volker Simonis, who did the investigation and did 
the first attempt at fixing it.
    https://bugs.openjdk.java.net/browse/CODETOOLS-7902799

  *) If -Djmh.ignoreLock=true is supplied, JMH no longer tries to create the lock. This apparently 
helps JMH IDE plugins that elect to ignore the lock:
    https://github.com/openjdk/jmh/pull/6

  *) ASM dependency upgraded to 9.0, which enables non-Java benchmarks to target modern JDKs. Thanks 
to Evgeny Mandrikov for this contribution:
    https://github.com/openjdk/jmh/pull/10

  *) A little UX improvement for Mac OS X "async" profiler users: mention DYLD_LIBRARY_PATH:
    https://bugs.openjdk.java.net/browse/CODETOOLS-7902804

   ...coincidentally, we have discovered a little deployment bug in async-profiler:
    https://github.com/jvm-profiling-tools/async-profiler/issues/378

  *) JMH was unable to compile the benchmark with multiple referenced Benchmark states, due to 
benchmark generator bug. This was discovered Michal Cervenansky, and his MCVE helped to nail this issue:
    https://bugs.openjdk.java.net/browse/CODETOOLS-7902807

  *) Batch size tests used to intermittently fail in our CIs, and in the end we discovered that not 
only the test is flaky, there are also rounding errors in benchmark scaffolding, which may give 
inaccurate measurements on batchSizes > 1.
    https://bugs.openjdk.java.net/browse/CODETOOLS-7902808

  *) @State cycle validation code was relying on odd stack-overflow catching, and thus was not very 
reliable. It is fixed now with the more straight-forward implementation; it is still recursive, but 
it does not rely on SOE anymore:
    https://bugs.openjdk.java.net/browse/CODETOOLS-7902805

Enjoy!

-- 
Thanks,
-Aleksey