RFR: 8304824: NMT should not use ThreadCritical [v9]

Thomas Stuefe stuefe at openjdk.org
Wed Oct 30 15:38:20 UTC 2024


On Mon, 28 Oct 2024 16:12:39 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 two additional commits since the last revision:
> 
>  - add a comment explaining lock rank
>  - remove unnecessary dropping of tracking level

We should get rid of this awful value correcting for arenas. I get headaches trying to think about this every time.

To remind everyone including me, some of the stuff is explained here:  [complex](https://bugs.openjdk.org/browse/JDK-8325890) . 

About locking around os::free - not sure if we can do this. Are all paths inside os::free lock free? It does call NMT. I think all cases inside NMT that touches are lock free, but am not sure. Have to think about this a biot.

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

PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2447570321


More information about the serviceability-dev mailing list