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

[Thomas Stuefe]

On Fri, 1 Mar 2024 22:25:14 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> In summary mode, we don't show/use the stack traces. So, it is possible to use `BitMap` for sub-regions of a reserved region. A bit is used for every page in the reserved region and is 1 when committed and 0 when uncommitted.
> No need to handle split/merge/exclude and any other similar operations on sub-regions. We just set/clear the bits accordingly.
> 
> To find the actual amount of committed/uncommitted memory, we just count the 1 bits before the operation and adjust the request size appropriately. For example:
> 
>                                               1         2
> Bit index:                          01234567890123456789012
> Current state of a reserved region: 11111000000111110000111
> commit sub-region [8,15):                   ^-----^       
> already-committed = 4
> actual-committed = (15 - 8) - 4 = 3

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.

1 GB range, fully uncommitted, 4K pages, needs a 32K bitmap. 

- 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.
- Counting means population counts on 32K memory (4096 word loads). 
- 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.

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

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