Inline Compiler Control confused in 0.3.1?

Aleksey Shipilev aleksey.shipilev at oracle.com
Fri Jan 31 00:54:38 PST 2014


On 01/31/2014 06:57 AM, Bernd Eckenfels wrote:
> I think the reason is the "confused" compiler control file:

Thanks! Indeed it is: with 0.3.1 we are forcing inline of @GMB methods,
and that collides with the explicit annotations you might have. Fixed,
along with simple regression test:
  http://hg.openjdk.java.net/code-tools/jmh/rev/f2e982b7c51b

> The full output and source code tested can be found here:
> 
> https://gist.github.com/ecki/919b4426fb01c0711b8f
> 
> BTW: what do you think, is the usage of blackhole to enforce field
> access enough, and is it fine to use the default thread state for this
> test type?

I think blackhole is enough. Also, it puzzles me why people are not
using the shortcut of just returning the value when there is only a
single result to consume. JMH will feed the return value into the
implicit blackhole.

> BTW2: the reason why I was testing different versions in the first
> place was that I was looking to the -s and -tc options to test with
> different threads automatically, but both seems to not have it. Any
> idea where those options (I have seen then in a blog post) are coming
> from?

We opted to remove these options because they complicated the runner
beyond reason. Use Java API to run with different options in one
sitting, like the JMH samples do.

-Aleksey.



More information about the jmh-dev mailing list