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

[Thomas Stuefe]

On Fri, 24 May 2024 06:25:20 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> I'm going to take some time to digest these ideas. I'm not a fan of the string-based approach, I much prefer longer but more obvious code. The latter approach might work out. Still, a general tool is to me not preferable. The typical case is probably not that you need to read every test case, but a specific one which fails. Having some repetition in other tests shouldn't bother you then, but having to jump into a generalized DSL for state assertions do.
>> 
>>>This doesn't really test the state, nor the stack. It also seems to be a lot of code for a single-use test. Similar in other tests.
>> 
>> Sorry, I don't understand what you mean by this.
>
>>> This doesn't really test the state, nor the stack. It also seems to be a lot of code for a single-use test. Similar in other tests.
> 
>> Sorry, I don't understand what you mean by this.
> 
> 
> You test that after committing, we have four nodes. You don't test that we have reserved-committed-reserved, nor the associated stacks (all equal), nor the flags. The test would be more interesting if you were to verify the region data, too.

> I'm going to take some time to digest these ideas. I'm not a fan of the string-based approach, I much prefer longer but more obvious code. The latter approach might work out. Still, a general tool is to me not preferable. The typical case is probably not that you need to read every test case, but a specific one which fails. Having some repetition in other tests shouldn't bother you then, but having to jump into a generalized DSL for state assertions do.

But is this really so far away from what you are doing, just a lot less code? The smaller the code, the smaller the barrier against new tests. And I could think off-head of a lot of tests missing.

Thinking about it, 24 different region states is probably too much. If we go for, say, 12 states, that increases the chance of merging in the random tests. So you pre-define, constant, 12 different region data with clear names. Those you use to reserve/commit, and to check the tree state.

I would really like this VMA tree be tested well. One reason is that its compelling to reuse it in other scenarios. In fact, I am eagerly awaiting your push so that I can play with it e.g. in Metaspace, or in ZGC.

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

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