hang when using -XX:-UseCompilerSafepoints
Deneau, Tom
tom.deneau at amd.com
Wed Nov 12 16:52:13 UTC 2014
Hi all --
Forwarding a thread which came about on the jmh-dev mail list, as recommended by Aleksey Shipilev (see below). The JMH framework has a timing control thread which sleeps for a certain period, then sets a volatile isDone variable. Meanwhile, the benchmark thread loops doing its benchmark code and also checking the isDone field. A hang occurs if -XX:-UseCompilerSafepoints is used.
The original issue can be reproduced by the following steps
hg clone http://hg.openjdk.java.net/code-tools/jmh
cd jmh
mvn clean install -DskipTests=true
cd jmh-samples
java -server -XX:-UseCompilerSafepoints -jar target/benchmarks.jar 'JMHSample_01_.*' -t 1 -wi 5 -i 5 -f 0
-- Tom Deneau
-----Original Message-----
From: Aleksey Shipilev [mailto:aleksey.shipilev at oracle.com]
Sent: Wednesday, November 12, 2014 6:09 AM
To: Deneau, Tom; jmh-dev at openjdk.java.net
Subject: Re: using -XX:-UseCompilerSafepoints
Hi Tom,
On 11/11/2014 07:34 PM, Deneau, Tom wrote:
> It looks like a thread that calls Thread.sleep (as the timing control
> thread does in the harness) will eventually go thru
> SafepointSynchonize::block (as part of the ThreadBlockInVM
> destructor). So if there is a looping benchmark thread compiled
> without Compiler Safepoints, the control thread will be blocked and
> will never set the isDone flag.
So, you are saying that without the safepoint in the while(!isDone)
loop in workload, control thread and workload thread will never
rendezvous on safepoint? I believe this is a bug with
-XX:-CompilerSafepoints, because the comment in safepoint.cpp calls this
out specifically for VMThread vs. Mutator threads:
// In a pathological scenario such as that described in CR6415670
// the VMthread may sleep just before the mutator(s) become safe.
// In that case the mutators will be stalled waiting for the safepoint
// to complete and the the VMthread will be sleeping, waiting for the
// mutators to rendezvous. The VMthread will eventually wake up and
// detect that all mutators are safe, at which point we'll again make
// progress.
If this is a case, you probably need to report this to runtime guys.
> This is probably OK, just need to document that CompilerSafepoints
> cannot be turned off.
I think it is safe to presume something will go hairy if you are using
any special VM flag, therefore I am not inclined to document this.
Thanks,
-Aleksey.
More information about the hotspot-runtime-dev
mailing list