Inline Compiler Control confused in 0.3.1?

Bernd Eckenfels ecki at zusammenkunft.net
Thu Jan 30 18:57:35 PST 2014


Hello,

I was using JMH to check varous "safe" concurrent access methods to
fields (mostly for singletons). I played a bit around with the various
options to get a feeling for the harness.

I noticed that with 0.2.1 the @CompilerMode annotation works pretty
much like expected:

Benchmark                                     Mode   Samples
Mean   Mean error    Units n.e.t.j.SingletonAccess.measureVolatile
thrpt         3      172,856        1,945   ops/us
n.e.t.j.SingletonAccess.measureVolatileE     thrpt         3
12,148        0,540   ops/us
n.e.t.j.SingletonAccess.measureVolatileI     thrpt         3
172,420       15,093   ops/us
n.e.t.j.SingletonAccess.measureVolatileNI    thrpt         3
103,293       11,850   ops/us

(E=exclude, I=force inline, NI=disable_inline and no sufffix=default).

But with 0.3.1 it looked wrong (i.e. no differences in the results):

Benchmark                                     Mode   Samples
Mean   Mean error    Units
n.e.t.j.SingletonAccess.measureVolatile      thrpt         3
172,856        1,945   ops/us
n.e.t.j.SingletonAccess.measureVolatileE     thrpt         3
12,148        0,540   ops/us
n.e.t.j.SingletonAccess.measureVolatileI     thrpt         3
172,420       15,093   ops/us
n.e.t.j.SingletonAccess.measureVolatileNI    thrpt         3
103,293       11,850   ops/us

I think the reason is the "confused" compiler control file:


quiet
inline,org/openjdk/jmh/logic/BlackHole.*
dontinline,net/eckenfels/tests/jmh/SingletonAccess.measureAtomicNI
dontinline,net/eckenfels/tests/jmh/SingletonAccess.measureFieldNI
dontinline,net/eckenfels/tests/jmh/SingletonAccess.measureSyncNI
dontinline,net/eckenfels/tests/jmh/SingletonAccess.measureVolatileNI
dontinline,net/eckenfels/tests/jmh/generated/SingletonAccess_.*
exclude,net/eckenfels/tests/jmh/SingletonAccess.measureVolatileE
inline,net/eckenfels/tests/jmh/SingletonAccess.measureAtomicI
inline,net/eckenfels/tests/jmh/SingletonAccess.measureAtomicNI
inline,net/eckenfels/tests/jmh/SingletonAccess.measureFieldI
inline,net/eckenfels/tests/jmh/SingletonAccess.measureFieldNI
inline,net/eckenfels/tests/jmh/SingletonAccess.measureSyncI
inline,net/eckenfels/tests/jmh/SingletonAccess.measureSyncNI
inline,net/eckenfels/tests/jmh/SingletonAccess.measureVolatile
inline,net/eckenfels/tests/jmh/SingletonAccess.measureVolatileE
inline,net/eckenfels/tests/jmh/SingletonAccess.measureVolatileI
inline,net/eckenfels/tests/jmh/SingletonAccess.measureVolatileNI

it produced "inline" commands for the NI and E variants.

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?

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?

Gruss
Bernd


More information about the jmh-dev mailing list