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

Patricio Chilano Mateo pchilanomate at openjdk.java.net
Wed Aug 25 21:39:23 UTC 2021


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

-------------

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


More information about the hotspot-dev mailing list