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

[Gerard Ziemski]

On Thu, 24 Apr 2025 07:59:01 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> Whatever approach we take, all the semantics, impl and test-cases should be easily understandable and maintainable. In future we may receive RFEs like these:
> 
> * test-case TTT fails if PPPP is true
> * regions with different call-stacks should not merge
> * it is preferred to store call-stacks for uncommit operations
> * re-committing a region should/not change the MemTag
> 
> then we need to dig into the semantics, impl and test-cases to find the reason and also the appropriate fix. I'd rather to have a straightforward approach for all the semantics. I think for handlining a request `(op, A, B, tag, call-stack)` we can do something like this: 

- 1- how [A,B) overlaps with existing nodes. decompose overlaps into sub-regions. 
- 2- what is the new state of overlapped regions 
- 3- what is the new tag of overlapped regions 
- 4- what is the new reserve-call-stack of overlapped regions 
- 5- what is the new commit-call-stack of overlapped regions 
- 6- what is the summary diff of the result
- 7- any new node to be inserted? 
- 8- if any existing node to be deleted? or to be updated?

Yes, my ideas were among the same lines. If we could do 1 on you list in some graphical way, ex:


pre:
----*************----
request insert:
--A******B----------
post:
--***************----


I would be thrilled. As far as I am concerned you are on the right track, please continue and let us see more!

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

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