RFR: 8335091: NMT: VMATree reserve_mapping and commit_mapping APIs need MEMFLAGS while un/-committing API has no MEMFLAGS arg [v8]

[Gerard Ziemski]

On Sat, 21 Sep 2024 18:22:49 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> In committing a region, it is not mandatory to provide a MEMFLAGS flag where the committed region inherits the flag from the main region it resides in.
>> In un-committing there is no need to a  MEMFLAGS at all. 
>> The `register_mapping` API of the VMATree *requires* a MEMFLAGS (via metadata arg) in both of these two operations. To do the flag inheriting, it is possible to copy the flag of the left node in the tree to the newly inserted ones. 
>> 
>> An optional bool arg (default is false) is added to VMATree API to copy the existing flag of the left node to the new nodes.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   logging/log.hpp is included

src/hotspot/share/nmt/vmatree.hpp line 184:

> 182:   SummaryDiff commit_mapping(position from, position sz, const RegionData& metadata, bool copy_flag = false) {
> 183:     return register_mapping(from, from + sz, StateType::Committed, metadata, copy_flag);
> 184:   }

Why do we need this API? It's only used in the test so far, so do we really need it?

I am not too crazy about `register_mapping` basically being a wrapper around `register_mapping(.., true)`

What if someone calls `commit_mapping(.., true)` ? Doesn't that turn into `register_mapping(..., StateType::Committed, metadata, true)` which is the same as `uncommit_mapping()` ? It doesn't make sense?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20330#discussion_r1773743712