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

[Mikael Gerdin]

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.

/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