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