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

[Johan Sjölen]

On Fri, 22 Mar 2024 14:06:59 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Johan Sjölen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Include os.inline.hpp
>
> src/hotspot/share/nmt/vmatree.hpp line 312:
> 
>> 310:   }
>> 311: 
>> 312:   SummaryDiff commit_mapping(size_t from, size_t sz, Metadata& metadata) {
> 
> So, the `Merge` template parameter only tries to solve the problem that callers don't specify MEMFLAGS on commit or uncommit, right?
> 
> We can
> - rethink that; require all callers of commit/uncommit to provide MEMFLAGS too. I know I have been arguing against it, but I like the simpler implementation of NMT. And arguably, it closer reflects `mmap` realities, where reserving and committing don't have the same roles as in hotspot.
> - don't make merging a topic for the tree. If we want the MEMFLAGS from prior reservations to carry over, just search the tree prior to registering the mapping. Since we need a "tell me the region this pointer points to" functionality anyway, just let's reuse that one. 
> - or, at least, revert to a simple bool or enum that describes merging behavior. Keep it simple and stupid.

Right, merging isn't even a complete solution. Consider this situation:

```c++
Tree tree;
tree.reserve_mapping(0, 50, mtNMT);
tree.reserve_mapping(50, 50, mtTest);
tree.commit_mapping(0, 100);


The current merge-strategy results in:


0    mtNMT   100
|                       |


While we *actually* wanted:


0 mtNMT  50   mtTest 100
|                 |                     |


Now, we happen to be safe from this behavior as our current `VirtualMemoryTracker` doesn't allow this kind of call anyway.

I really want solution 1, it just makes sense. I don't want to make that change though :-). Not right now, at least.

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

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