RFR: 8226228: Make Threads_lock an always safepoint checked lock.

Doerr, Martin martin.doerr at sap.com
Fri Sep 6 12:56:08 UTC 2019


Hi David,

thank you for pointing me to that bug and for adding the information as a comment.

Best regards,
Martin


> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Freitag, 6. September 2019 14:31
> To: Doerr, Martin <martin.doerr at sap.com>; Robbin Ehn
> <robbin.ehn at oracle.com>
> Cc: hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR: 8226228: Make Threads_lock an always safepoint checked
> lock.
> 
> https://bugs.openjdk.java.net/browse/JDK-8229778
> 
> David
> 
> On 6/09/2019 10:26 pm, David Holmes wrote:
> > Not Robbin but ...
> >
> > On 6/09/2019 8:57 pm, Doerr, Martin wrote:
> >> Hi Robbin,
> >>
> >> we have seen the test
> vmTestbase/nsk/jdb/watch/watch001/watch001.java
> >> running into fatal() in Thread::check_for_valid_safepoint_state:
> >>    if (((JavaThread*)this)->thread_state() != _thread_in_vm) {
> >>      fatal("LEAF method calling lock?");
> >>    }
> >>
> >> With the following stack:
> >> Thread::check_for_valid_safepoint_state(bool)
> >> Mutex::lock(Thread*)
> >> Mutex::lock()
> >> JavaThread::block_if_vm_exited()
> >> SafepointSynchronize::block(JavaThread*)
> >> SafepointMechanism::block_if_requested_slow(JavaThread*)
> >> JavaThread::check_special_condition_for_native_trans(JavaThread*)
> >>
> >> Thread:
> >> =>0x000000011590c800 JavaThread "output reader"
> >> [_thread_in_native_trans, id=5918,
> >> stack(0x00000001180a0000,0x00000001182ad888)]
> >>
> >> Last Event:
> >> Event: 8.870 Executing VM operation: Exit
> >>
> >> Sounds like this is related to this change. Do you agree?
> >
> > yes this failure is caused by the change to make the Threads_lock a
> > safepoint-always lock. The lock() in block_if_vm_exited() does not need
> > to check for a safepoint as it simply wants to block the thread
> > permanently on the locked Threads_lock. But before we get that far we
> > now check the safepoint state and so hit the assertion.
> >
> > We've had a report of this in the bug system but there was no stack and
> > no reproducer.
> >
> > Thanks,
> > David
> > -----
> >
> >> Best regards,
> >> Martin
> >>


More information about the hotspot-runtime-dev mailing list