JMH 1.7.1

[Aleksey Shipilev]

Hi,

JMH 1.7.1 is released and available at Maven Central (thanks to Evgeny,
as usual). This is a maintenance release, and it includes a few bugfixes
and improvements.


 * -prof perfnorm reports clocks-per-instruction (CPI) now, like -prof
perf does. CPI is an important derivative metric, so it makes sense to
compute it always. Tracking:
    https://bugs.openjdk.java.net/browse/CODETOOLS-7901361


 * -prof perfnorm provides more counters now. Turns out, "perf stat -d
-d -d" misses some interesting counters. Therefore, we are now listing
the gathered events explicitly (after checking those are acceptable on a
given platform). Fallback to old behavior is possible with
-Djmh.perfnorm.useDefaultStat=true. Tracking:
    https://bugs.openjdk.java.net/browse/CODETOOLS-7901364


 * Selectable score precision and treating near-zero results. The
experience with -prof perfnorm identified a usability problem when some
metrics have low values and round towards zero. It is not an issue for
benchmark scores, because users are supposed to choose the timeunit
wisely. However, perfnorm results are normalized to benchmark op, and
therefore exempt from TU settings. Thus, perfnorm may report "0.000" for
metrics that are not actually zero.

  We have implemented a special treatment for "zeroed" results. Instead
of printing out "0.000", we now print the order of magnitude for the
value, in order to distinguish these small values from zeroes, like this:
   http://cr.openjdk.java.net/~shade/jmh/counters-not-zero.png

 Additionally, JMH power users can now control the score precisions with
-Djmh.scorePrecision=#; instead of defaulting to three decimal places
after the point. This option can be used to promote the "shortened"
scores into the proper ones.

 Tracking:
   https://bugs.openjdk.java.net/browse/CODETOOLS-7901365


 * JMH handling of space-containing jvmArgs was improved. We now both
accept the spaces shielded by quotes, as well as multiple -jvmArgs that
describe the individual options. This should help all OS launcher quirks
we know about. Tracking:
   https://bugs.openjdk.java.net/browse/CODETOOLS-7901362


 * Some "compound" annotations like @Fork used to override all the
parameters at once. E.g. if there was a @Fork annotation on method that
sets fork times, and then a @Fork annotation on class that added a
jvmArg, the class-level one completely obliterated the method-level one.
This is changed now, and it slightly changes the JMH behavior. That
said, the previous behavior was deliberately unspecified, so relying on
either one is tricky anyhow. Tracking:
   https://bugs.openjdk.java.net/browse/CODETOOLS-7901330


 * @Benchmark methods with the same name, but different signatures are
treated by the Java language as distinct methods. However, as far as JMH
is concerned, this yields an ambiguity. Users have faced a cryptic
message in the cases like this. Fixed:
   https://bugs.openjdk.java.net/browse/CODETOOLS-7901363


 * JMHSample_34_SafeLooping sample, describing how to achieve (an
arguably) safe looping when needed:
   http://hg.openjdk.java.net/code-tools/jmh/rev/fceec061059d

Enjoy!

-Aleksey.