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

[Coleen Phillimore]

On Mon, 30 Aug 2021 02:17:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reverse the order of safepoint_check_required and allow_vm_block arguments so that the first can imply the value of the second.  This is good because if we decide to rename the second to something like _allow_safepoint_use instead there's less to change. Also remove default arguments as they are evil.
>
> src/hotspot/share/gc/shared/taskTerminator.cpp line 75:
> 
>> 73:   _queue_set(queue_set),
>> 74:   _offered_termination(0),
>> 75:   _blocker(Mutex::leaf, "TaskTerminator", Monitor::_safepoint_check_never),
> 
> Is this lock even used by any JavaThreads? I'm guessing not - in which cases the always/never and allow/not-allow are immaterial, and the change is harmless.

I see no evidence of this lock being taken by JavaThreads

> src/hotspot/share/gc/z/zMetronome.cpp line 31:
> 
>> 29: 
>> 30: ZMetronome::ZMetronome(uint64_t hz) :
>> 31:     _monitor(Monitor::leaf, "ZMetronome", Monitor::_safepoint_check_never),
> 
> Again the "false" to "true" stands out here, but again I have to assume this is not a lock that is used by JavaThreads. Makes me wonder whether these locks can never encounter contention by the VMThread (otherwise they would assert).

Also appears that this is only taken by GC threads.

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

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