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

[David Holmes]

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
>