RFR(XS): 8043070: nmethod::verify_interrupt_point() shouldn't enter safepoint
Mikael Gerdin
mikael.gerdin at oracle.com
Wed May 14 11:20:41 UTC 2014
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
More information about the hotspot-compiler-dev
mailing list