RFR: 8327152: NMT: use BitMap for committed memory regions in summary mode
Johan Sjölen
jsjolen at openjdk.org
Wed Mar 6 10:18:46 UTC 2024
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
Hi,
If this is going to be used as an alternative strategy for small allocations in summary mode then we need to know the point at which these are better than VMATrees. Could you wait until my PR is up for review at least before doing those comparisons?
The main issue with a bitmap is when reservation become quite large, which they would be in the case of Metaspace and Java heap. Consider a 128GiB Java heap, not unheard of, this would have a 4MiB bitmap. That's actually quite significant and non-obvious how performant it is.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/18090#issuecomment-1980528997
More information about the hotspot-runtime-dev
mailing list