RFR: 8272797: Mutex with rank safepoint_check_never imply allow_vm_block [v3]

[coleen.phillimore at oracle.com]

On 8/25/21 5:39 PM, Patricio Chilano Mateo wrote:
> On Wed, 25 Aug 2021 19:38:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>
>>> See CR for details.  This essentially makes Mutex that safepoint_check_never imply a NoSafepointVerifier, which is a stronger and simpler invariant.
>>> Tested with tier1-6.
>> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>>
>>   - Merge branch 'master' into never-block
>>   - Add simple gtest.
>>   - 8272797: Mutex with rank safepoint_check_never imply allow_vm_block
> I agree it makes sense for _safepoint_check_never to imply also NSV. Otherwise a deadlock could happen if the JT blocks for a safepoint in the critical region while there is another JT waiting to acquire the _safepoint_check_never lock, since the safepoint will never start. I guess we don't have such cases today.

You're right, that is a possible deadlock.

> If the _allow_vm_block flag is now always true with _safepoint_check_never then I wonder if we should have a separate constructor for the _safepoint_check_never locks that doesn't have the extra boolean parameter and that just calls the current constructor with _allow_vm_block=true.

This is a good idea.  The mutexLocker.cpp definitions are done with a 
macro, so I wouldn't change them but it would remove an obvious 
parameter from the other constructor callers.

thanks,

Coleen

>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/5218