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