RFR: 8312132: Add tracking of multiple address spaces in NMT [v46]

[Thomas Stuefe]

On Fri, 3 May 2024 08:25:04 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:

>> I think we should rethink recording specific stacks for uncommitted memory. I don't believe anyone cares who reserves uncommitted memory; or who uncommits memory. And this only leads to splintering the tree, if we uncommit from different callsites. We should consider keeping stacks for committed memory only, and use some noop stack placeholder for uncommitted mmeory.
>
> The issue, as I see it, is that we think of committing memory as a "layering" on top of reserving memory, and when that commit goes away the underlying layer of reserved memory is exposed again. In our VMATree, we don't store that underlying reservation anymore.
> 
> So what to do? If we add callstack and MEMFLAGS for uncommitting memory then that's an easy solution. The best would be to keep VMT's semantics here. We can do that, if the metadata stored is doubled in size per node and we recognise this pattern.
> 
> Still, I'll re-iterate: This is a problem for tomorrow, when we do port VMT.

Note that the callstack information will be wrong for uncommitted memory though, since what should happen is that the now-again-reserved region should be re-accounted to the callstack that originally did the total reservation, not the callstack now doing the uncommitting.

But tbh, as much as I used NMT with customer cases over the years, the detail view with callstacks was never of much use for the mmap case anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18289#discussion_r1592450143