hang when using -XX:-UseCompilerSafepoints

[Vladimir Kozlov]

I agrer that workaround is -Xint. But if we disable compilation with 
-UseCompilerSafepoints, the flag becomes useless. You can get the same 
result with just -Xint.

The history shows that it was added at the very beginning of Hotspot 
development, at the day one. I can only speculate that it was used to 
find performance effects of safepoints in compiled code . It could be 
the case that we removed safepoints from Counted loops as result of that 
investigation. I think it was never intended to be used in production.

Although we can fix compilers to generate a runtime call which does 
safepoint when -UseCompilerSafepoints is specified, it will be useless 
work, I think.

thanks,
Vladimir

On 11/12/14 6:57 PM, David Holmes wrote:
> On 13/11/2014 9:38 AM, Vladimir Kozlov wrote:
>> 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.
>
> Well, it disables the mechanism that the compiler inserts for checking
> if a safepoint has been requested. As I've added to the bug report,
> disabling compiler safepoints should go hand-in-hand with disabling the
> compilers (ie run with -Xint) - otherwise you have to know that the
> compiled code will eventually hit a non-compiler safepoint check.
>
>> 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!
>
> If we assume there is a reason it was made a product flag then the
> correct fix in my opinion would be to fall back to intepreter-only mode
> when this flag is turned off.
>
> If we don't make that assumption then we could still tie it to
> interpreter-only mode, but we definitely should not make it configurable
> in product mode without some effort.
>
> Or if we can't ascertain a valid reason for ever wanting to do this, we
> could simply delete the flag altogether. :)
>
> Cheers,
> David
>
>> 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.
>>>>
>>>
>>>