JMH v0.9

[Aleksey Shipilev]

Hi there folks,

JMH 0.9 was promoted in Maven Central (thanks Evgeny!):
 http://central.maven.org/maven2/org/openjdk/jmh/jmh-core/0.9/

This version is officially Feature Complete, and we do not anticipate
other user-visible changes before 1.0. Now, we have a stabilization
period before starting release candidate work, which should culminate in
releasing JMH 1.0 in July.

It is very important for you to migrate to 0.9 as soon as possible, and
give it a round of testing. The issues discovered in a next few weeks
are the issues which have the highest probability to be fixed before
1.0, so please arrange the time to try 0.9 out. [*]

RELEASE NOTES:

* @GenerateMicroBenchmark is now @Benchmark! Search-and-replace in your
old code, and you are set to go.

* Default time unit for the run is now SECONDS. Most people are defining
their own @OutputTimeUnit(...) right away, so this should not affect a
lot of users. The starter benchmarks coming from archetypes would
measure throughput in ops/sec.

* Painful regression introduced in 0.8 was fixed: when doing
multi-threaded benchmarks with Throughput mode, JMH mistakenly averages
the results of different threads when aggregating the benchmark score.
This is the only mode affected, and it only affects multi-threaded
benchmarks. Having a very few users migrated to 0.8 yet, and the bug was
discovered only yesterday, it seems a good idea to release 0.9 instead
of releasing patched 0.8.1. (The whole thing was rather embarrassing,
and highlighted a slip in our testing coverage. Tests are beefed up now).

* BenchmarkParams, IterationParams, and ThreadParams are now injectable.
These infrastructure classes provide the view into current harness
environment, including current iteration duration, thread counts, thread
group distributions, etc. See the JMH sample here:
 http://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_31_InfraParams.java

* For JVM languages support, we want to give up on supporting ASMv4-only
parser, and instead use the ordinary Reflection thus piggybacking on JVM
itself to parse the class files. Users already having the (non-Java) JMH
projects will be switched to "reflection" generators automatically in
0.9 onwards.

If you experience the problem with reflection generators, you can hack
your build file and request "asm" back, see how it's done in updated
archetype:
http://hg.openjdk.java.net/code-tools/jmh/file/293f2e0ab454/jmh-archetypes/jmh-scala-benchmark-archetype/src/main/resources/archetype-resources/pom.xml#l108.
Don't forget to tell us about your problems, so we can reconsider the
switch!

* Archetypes are cleaned up a bit to keep jmh-core and jmh-generator-*
dependencies in sync. Too many users forget to update one of them when
moving to newer JMH.

* Archetypes now set to generate "benchmarks.jar" instead of
"microbenchmarks.jar". Your existing JMH projects are not affected, but
new project bootstrapped from archetype will have the new uberjar name.

* @Param-s without arguments will now be rejected by JMH at compile
time. Before that, we waited for user to provide the value in runtime,
and lacking user input, fail there. We have reconsidered this for two
reasons: a) it does not play nicely with lots of benchmarks in the large
suites -- a lone underspecified benchmark ruins the run for every other
well-behaved benchmark; and b) it does not play well with implicit
@Param(<enum>), see below.

* Joe Kearney had done the change to support implicit @Param(<enum>).
When placed over enum field, @Param will implicitly have all enum
constant as the default parameter set. Only the enums provide such
luxury of small countable parameter sets, so it works only for them.

* Runner and Results API were rebuilt. That includes hiding the
BenchmarkRecord which accidentally leaked into public API from the API
prototype. If you miss something that was present in the API before, it
is a good idea to tell this now.

* Many internal classes were moved around to their final destinations.
If you experience compilation failures with new JMH, please try scratch
your import declarations, and let IDEs to figure them out anew. If you
can't find the class you were relying on, it might got hidden. Please
try to look around how to re-implement things with current API, or tell
us about your problem if you can't find the substitute.

* Host/Forked VM interface was reworked to do the most of the option
parsing work at Host VM. This also enables CPU count auto-detection to
be done only once on Host VM. Not only this helps benchmark run times,
it also keeps SingleShot benchmarks to run in decently cold environments.

* Javadocs are improved across the board.

Enjoy!

Thanks,
-Aleksey.

[*] To further emphasize how serious I am, I'll be spending the next 12
days in Italy, and I fully expect lots of comments in the mail when I
get back.