On Mon, 28 Oct 2024 16:12:39 GMT, Robert Toyonaga <d...@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 Ok so there shouldn't be reentrancy if we use the `NmtVirtualMemory_lock` around `os::free`. But we also free in `ChunkPool::prune()` : >> I'm not certain, but looking at it again, it seems that the ThreadCritical >> uses in ChunkPool::deallocate_chunk and ChunkPool::prune() are only needed >> for NMT and are independent of the other ThreadCritical uses in that code. >At least for prune, that's needed for the chunk pool itself as it would >otherwise be accessed concurrently. So that means we'd need to have both `ThreadCritical` and `NmtVirtualMemory_lock` in that method (if we were to do the other replacements). One to protect the chunks and one to protect the malloc accounting. It might also be good to rename `NmtVirtualMemory_lock` then too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2447631841
