JMH v0.8
Aleksey Shipilev
aleksey.shipilev at oracle.com
Fri May 30 22:18:32 UTC 2014
Hi,
We had promoted JMH v0.8 (thanks again, Evgeny!). This release is
special for a few reasons, which I'll explain below. This release marks
the start of ramp-down phase which should culminate in releasing 1.0.
Please help us with testing current release early!
Back to 0.8. Let us start with some to pay attention to.
THE NUISANCES PART:
* Internal APIs are moved around between packages. If you used Java API
to access JMH, your code may stop compiling after upgrading to 0.8.
Don't worry, the code semantics had not changed, but you might want to
ask your IDEs to re-resolve the imports to find the JMH classes at the
new locations. We will probably have some other moves before 1.0. This
does not affect those using JMH CLI launcher.
* Notably, BlackHole is moved, and was renamed to Blackhole (a little
pet peeve of ours). If your code uses explicit Blackholes for no good
reason, it is a good idea to use implicit returns which will have the
same effect. E.g. instead of:
@GMB
public void test(BlackHole bh) {
bh.consume(myWorkMethod());
}
...it is future-safe to write:
@GMB
public long test() { // or whatever the return type is
return myWorkMethod();
}
There are no performance implications in using either construct, so
choose the cleaner one (second, obviously).
* "Mean"/"Mean error" columns in final report were renamed to "Score",
since some metrics are not aggregated via the mean, but instead report
max/min/last result. It is misleading to report them as "mean" in these
cases. If your scripts grepped the human-readable JMH output for these
words, prepare for breakage. It is advised to use machine-readable
outputs (see -rf) though.
* Quite a few internal classes were made really internal, i.e. not
public. If you think some class should be turned back to public, please
speak up.
That concludes the "nuisance" parts. Now...
THE GOOD PARTS:
* Massively rewritten profiler interface. It was hanging up in the air
for years before. Now, the profilers can be plugged in: implement one of
Profiler sub-interfaces, feed it to Runner via the Java API, and you are
set to go. The internal interface is still a bit rough around the edges,
but we will appreciate people trying to implement their own profilers.
We hope that many cases where people abused @AuxCounters to plug in the
auxiliary information, can be cleanly implemented via Profilers.
* Profilers are now dumping the secondary results straight to where
other results are. Asymmetric benchmarks were the only users of those
"secondary" results before, now profilers produce secondary results as
well. Pick your favorite workload, and run it with, say, "-prof gc" or
"-prof hs_comp" to see what changed.
* Linux perf profiler. To try out the new profiler interface, we added
the proof-of-concept profiler using awesome Linux perf tool, available
on most systems as the collateral package for Linux Kernel. If you have
perf installed, you can try "-prof perf" in JMH. This profiler is simply
calling the forked Java process under "perf stat" and prints its output.
It is possible to extract values from there into the reportable metrics,
but we will leave that as the exercise to the reader. (See
LinuxPerfProfiler.java, patches welcome!)
* Linux perf + PrintAssembly profiler. The more advanced profiler is
the one which uses the perf capability to map hardware counters back to
the machine addresses. This data can greatly contrast the relevant parts
of -XX:+PrintAssembly output, and this is what "-prof perfasm" does.
Obviously, you will need the -XX:+PrintAssembly-enabled JVM, and working
perf.
A few other useful things:
* @Param annotations now support enums. It was an accidental omission
on our part. Joe Kearney (on this list) had volunteered to improve the
enum support even further.
* Language archetypes are no longer bring jmh-bytecode-generator along
into the uberjar. This helps to keep ASM out which might have collided
with language runtimes.
* Detecting JMH annotations on super/sub-classes is bugfixed.
Thanks,
-Aleksey.
More information about the jmh-dev
mailing list