[jmm-dev] easily observable examples of non-sc behaviours in Java

[Aleksey Shipilev]

On 01/16/2015 11:38 PM, Francesco Zappa Nardelli wrote:
> Btw, I wasn’t aware of jcstress (cool tool!): is there a paper or doc
> that describes the techniques used to stress the compiler/vm to
> increase the chance that the interesting optimisations fire?

No. Unlike Litmus/DIY that have a good track record in publications,
jcstress is largely an engineering exercise that (yet) has little
academic background, except for building on what Litmus already did.


> Observing interesting behaviours is already tricky at the hardware
> level (e.g. the litmus tool makes a lot of memory noise before
> running the litmus tests), and I was wondering how to do the same at
> the language level.

jcstress does one big thing to capture interesting cases: runs as fast
as it possibly can -- this requires some JVM knowledge to pull off.
(This is one of the reasons why this project is interesting for me).

As part of that, jcstress generates the synthetic infrastructure code
for each test, which has the good chance to be translated to the fastest
machine code, because it avoids blocking ops, plays nice with inliner
and devirtualizer, etc. Look e.g. in:
 tests-custom/target/generated-sources/annotations/

As far as other "tricks" are concerned, these are off the top of my head:

 a) Re-allocate the test data each test "epoch". JVMs inevitably
randomizes this when multiple threads are allocating stuff. The nuisance
for predictable software otherwise, it plays for us here.

 b) Using @Contended to avoid false sharing for otherwise unrelated test
data. False sharing frequently demolishes interesting cases, e.g. if you
do the volatile read, you "acquire" not only the read itself, but
everything on the same cache line.

 c) Hotspot has experimental -XX:+StressLCM +XX:+StressGCM flags that
randomize the instruction scheduling. Coupled with multiple forks that
jcstress does, it helps to test different code layouts in machine code.
E.g. this bug (https://bugs.openjdk.java.net/browse/JDK-8007898)
reproduces nicely on PowerPC backend that aggressively pre-schedules
loads; but on x86 it only reproduces with -XX:+StressLCM -XX:+StressGCM.

 d) When available, jcstress is also making use of Hotspot's
Whitebox API and forces the test methods to get recompiled, further
stressing the randomized instruction scheduling.

One of these days we will make steps to properly document all this,
since all these techniques seem to be profitable. One of these days.

Hope this helps,
-Aleksey.