RFR (XS) 8237080: fatal error: VM thread could block on lock that may be held by a JavaThread during safepoint: SharedDecoder_lock

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Wed Jan 29 22:00:26 UTC 2020



On 1/29/20 1:32 PM, coleen.phillimore at oracle.com wrote:
>
>
> On 1/29/20 12:07 PM, Patricio Chilano wrote:
>> Hi Coleen,
>>
>> Looks good to me. Not for this change but seems all monitors that are 
>> _safepoint_check_never should have allow_vm_block to true since they 
>> will not be held during a safepoint. Based on the output message in 
>> check_block_state() that's what we are trying to avoid. Also we 
>> wouldn't be incrementing _no_safepoint_count in 
>> no_safepoint_verifier() otherwise, which I think is what we want if 
>> the monitor has the _safepoint_check_never flag.
>
> I was wondering if someone would ask this question.  Yes, you're 
> right.  I had a bigger change at one point that verified that 
> _safepoint_check_never flags always implied _allow_vm_block to be 
> true, but backed off in the interest of a less invasive change. There 
> were a few mismatched locks.
>
> I'll try the larger change, which does have the effect of 
> _safepoint_check_never always implying NoSafepointVerifier, which was 
> my intention in the previous cleanups.

Unfortunately, there are locks that are _safepoint_check_never where 
_allow_vm_block = false.  These locks _may_ want to assert that the 
VMthread never calls them.  The ZGC threads take locks with these values.

There are locks that are _safepoint_check_always where _allow_vm_block = 
true.  These locks are also taken by the VM thread.  The 
NoSafepointVerifier in the code for _allow_vm_block protect these locks 
from deadlocking by preventing safepoints while they are held.

As you pointed out, we only make a NoSafepointVerifier for locks that 
are _allow_vm_block = true, which covers many but not all of the 
_safepoint_check_never locks.   If I make it also check 
_safepoint_check_never, there's a JFR lock that very specifically 
violates this with comments.

I am going to stay with my first change for this bug fix.

Thanks,
Coleen
>
> thanks,
> Coleen
>>
>> Thanks,
>> Patricio
>>
>> On 1/28/20 6:36 PM, coleen.phillimore at oracle.com wrote:
>>> Summary: Set allow_vm_block to true for this lock.  It's 
>>> _safepoint_check_never so it's sort of implied (you can't safepoint 
>>> holding the lock and block out the vm thread).
>>>
>>> open webrev at 
>>> http://cr.openjdk.java.net/~coleenp/2020/8237080.01/webrev
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8237080
>>>
>>> Ran test case with hard-coded failure, and tier1-6.
>>>
>>> Thanks,
>>> Coleen
>>
>



More information about the hotspot-runtime-dev mailing list