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

[David Holmes]

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