RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v29]

[Afshin Zafari]

On Wed, 21 May 2025 19:44:18 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> For this case:
> 
> ```
>   {// Check committing into a reserved region inherits the call stacks
>     VMATree::RegionData call_stack_test(si_1, mtTest);
>     VMATree::RegionData call_stack_none(si_2, mtNone);
>     VMATree::RegionData call_stack_nmt(si_2, mtNMT);
>     Tree tree;
>     tree.reserve_mapping(0, 50, call_stack_test); // reserve in an empty tree
>     tree.commit_mapping(25, 10, call_stack_nmt, true); // commit at the middle of the region
>     tree.print_timeline_on();
>   }
> ```
> 
> I know that we are passing `true` for `use_tag_inplace` here, but it just does not feel right to get this:
> 
> ```
>           1         2         3         4         5         6
> 0123456789012345678901234567890123456789012345678901234567890123456789
> AAAAAAAAAAAAAAAAAAAAAAAAAbbbbbbbbbbCCCCCCCCCCCCCCC....................
> Legend:
> A - Test (reserved)
> b - Test (committed)
> C - Test (reserved)
> . - None (free/released)
> ```
> 
> I was expecting this:
> 
> ```
>           1         2         3         4         5         6
> 0123456789012345678901234567890123456789012345678901234567890123456789
> AAAAAAAAAAAAAAAAAAAAAAAAAbbbbbbbbbbCCCCCCCCCCCCCCC....................
> Legend:
> A - Test (reserved)
> b - Native Memory Tracking (committed)
> C - Test (reserved)
> . - None (free/released)
> ```
> 
> I don't think we should be allowing `use_tag_inplace` to modify the behavior this much. Instead of `use_tag_inplace` we could accept mtNone to inherit the tag already in place? No need for that extra parameter?

If we want to mtNMT tag be used for commit, we should pass `use_tag_inplace` as `false` or:
`tree.commit_mapping(a,b call_stack_nmt);`

commit + mtNone is an issue that Johan also mentioned/noticed. We have to define this new case, then I impl it.

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

PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2900358436