RFR(XS): 8043070: nmethod::verify_interrupt_point() shouldn't enter safepoint

[Igor Veresov]

Hm, I always thought for some reason that we safepoint before taking the lock. Thanks for pointing this out!
I’ll have to think about this a bit. This particular lock if not a leaf one, so simply making it of a no_safepoint kind everywhere is problematic.

igor

On May 14, 2014, at 4:20 AM, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:

> On Wednesday 14 May 2014 11.23.22 Mikael Gerdin wrote:
>> Igor,
>> 
>> On Wednesday 14 May 2014 01.35.46 Igor Veresov wrote:
>>> Would it be better if I assert that we don’t ever enter a safepoint in
>>> that
>>> scope? http://cr.openjdk.java.net/~iveresov/8043070/webrev.01/
>> 
>> Actually, I realized that Markus' bug is not the issue I thought it was.
>> What I meant was something similar to this bug which I fixed a while back:
>> https://bugs.openjdk.java.net/browse/JDK-8013129
>> 
>> Unfortunately I was scarce with details about the deadlock so I'm going to
>> backout the change and try to reproduce the deadlock to see the exact steps
>> it took to provoke it.
> 
> I managed to reproduce my earlier problem with mixing _no_safepoint_check_flag 
> on a single lock, here's how this can deadlock:
> 
> T1 is initiating a safepoint (for whatever reason)
> T2 is parked in Monitor::lock_without_safepoint_check -> Monitor::ILock
> T3 has returned from ILock in Monitor::lock and catches the safepoint in 
> ~ThreadBlockInVM
> 
> T2 will never reach the safepoint since it's blocking while _vm_running
> 
> I've updated https://bugs.openjdk.java.net/browse/JDK-8013129 with a stack 
> trace from a deadlocked VM.
> 
> /Mikael
> 
>> 
>> /Mikael
>> 
>>> igor
>>> 
>>> On May 14, 2014, at 12:39 AM, Igor Veresov <igor.veresov at oracle.com> 
> wrote:
>>>> Mikael,
>>>> 
>>>> I agree it’s ugly and we have to rethink the code management locks, but
>>>> it’s only dangerous if there is a safepoint-cooperating lock within the
>>>> scope of this one. There isn’t any, so I assume it should be safe.
>>>> Right?
>>>> 
>>>> igor
>>>> 
>>>> On May 14, 2014, at 12:04 AM, Mikael Gerdin <mikael.gerdin at oracle.com>
>> 
>> wrote:
>>>>> Igor,
>>>>> 
>>>>> On Tuesday 13 May 2014 18.11.48 Igor Veresov wrote:
>>>>>> nmethod::verify_interrupt_point() is called from as part of nmethod
>>>>>> verification from ciEnv::register_method() that asserts no safepoint
>>>>>> can
>>>>>> occur. However verify_interrupt_point() locks a mutex that may
>>>>>> potentially
>>>>>> safepoint. A sample call stack of when it happens is in the following
>>>>>> JBS
>>>>>> issue.
>>>>>> 
>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8043070
>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8043070/webrev.00/
>>>>> 
>>>>> It's unsafe to mix safepoint-aware and safepoint-ignoring locking on a
>>>>> single Mutex as that can deadlock the VM, see
>>>>> https://bugs.openjdk.java.net/browse/JDK-8039458
>>>>> 
>>>>> CompiledIC_lock is taken without _no_safepoint_check_flag at all other
>>>>> uses.
>>>>> 
>>>>> /Mikael
>>>>> 
>>>>>> igor
>