RFR: 8304824: NMT should not use ThreadCritical [v6]
David Holmes
dholmes at openjdk.org
Sun Sep 22 23:34:36 UTC 2024
On Fri, 20 Sep 2024 18:11:51 GMT, Robert Toyonaga <duke at openjdk.org> wrote:
>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT. `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT. I've implemented the new lock with a semaphore so that it can be used early before VM init. There is also the possibility of adding assertions in places we expect NMT to have synchronization. I haven't added assertions yet in many places because some code paths such as the (NMT tests) don't lock yet. I think it makes sense to close any gaps in locking in another PR in which I can also add more assertions.
>>
>> Testing:
>> - hotspot_nmt
>> - gtest:VirtualSpace
>> - tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>
> Inherit from ConditionalMutexLocker. Use current_or_null_safe instead of current_or_null.
src/hotspot/share/runtime/mutexLocker.cpp line 139:
> 137: Mutex* NMTQuery_lock = nullptr;
> 138: Mutex* NMTCompilationCostHistory_lock = nullptr;
> 139: Mutex* NMT_lock = nullptr;
Sorry just noticed the other NMT locks. I think we need a more descriptive name than just plain NMT_lock so the usage is more clear.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20852#discussion_r1770657123
More information about the serviceability-dev
mailing list