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

[Robbin Ehn]

Yes, thanks Martin and David!

/Robbin

On 2019-09-06 14:56, Doerr, Martin wrote:
> 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
>>>>