hang when using -XX:-UseCompilerSafepoints

[Aleksey Shipilev]

Hi,

Still not sure if this is a runtime bug: stripping safepoints from the
non-counted loop seems to be a recipe for disaster.

Anyhow, I think it deserves a simpler example. Submitted the bug and
attached a simple test there:
 https://bugs.openjdk.java.net/browse/JDK-8064749

Thanks,
-Aleksey.

On 12.11.2014 19:52, Deneau, Tom wrote:
> 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.
>