hang when using -XX:-UseCompilerSafepoints

[Vladimir Kozlov]

On 11/12/14 12:13 PM, Aleksey Shipilev wrote:
> Hi,
>
> Still not sure if this is a runtime bug: stripping safepoints from the
> non-counted loop seems to be a recipe for disaster.

This flag does not affect compiled code - so it is not compiler issue. 
It is only used in runtime/safepoint.cpp and it guards the code which 
protects a polling page.

There are many bugs which shows current problem. For example:

https://bugs.openjdk.java.net/browse/JDK-6873333

I would say that we have to remove it or at least make it experimental 
flag if we want to do experiments with it.

We definitely should not allow to use it in production!

Regards,
Vladimir

>
> 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.
>>
>
>