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

[Igor Veresov]

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/

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