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]

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.

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
>