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