RFR: 8327152: NMT: use BitMap for committed memory regions in summary mode

[Afshin Zafari]

On Tue, 5 Mar 2024 10:21:16 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> But we are currently discussing the rewrite of VMT using a VMATree. Why not wait for that? The proposed VMATree solution is better in both query speed and - unless you deal with insane levels of fragmentation - memory footprint. It is also less complex and more robust than either current code or this RFE.

This RFE is made for some improvement _besides_ the VMATree, and not replacing/ignoring it. For sure VMATree will improve the speed and together with this we hope/expect to gain more improvement. And as a reminder, this is only for Summary mode since the stack traces are not stored or used. 

> * Marking it as uncommitted means we need to zero-init 32K memory, 4096 word writes. A solution based on tree, similar to what we have now, only needs a few to a few dozen word writes.

We only do it at initialization, and not in every commit/uncommit.


> * Counting means population counts on 32K memory (4096 word loads).

At commit/uncommit, we only count the 1 bits within a _sub-range_ of the whole bitmap. Only at `committed_size()` we read this number of words.


> * Since we access at bit level, accesses need to be synchronized. This would cement the current need for a global lock for VMA registration - we would have navigated us into the "needs always a lock" corner and never get away from it.

Current code, and maybe future VMA, are already within a critical section (using `ThreadCritical`) at the `MemTracker::record_xxxx` calls. No new lock/sync is needed. 

VMATree can replace the `SortedLinkList` only for `ReservedMemoryRegions`. We can still use the bitmap for handling `CommittedMemoryRegions` and avoid caring about the overlapping sub-regions.

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

PR Comment: https://git.openjdk.org/jdk/pull/18090#issuecomment-1978700430