RFR: 8263464: NMT: assert in gtest os.release_multi_mappings_vm [v2]

[Gerard Ziemski]

On Mon, 8 May 2023 17:22:47 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> I tried to make a picture of the memory and the parts that should get released for testing:
>> 
>> 
>> //  allocate              [aaaa][bbbb][cccc][dddd]
>> 
>> //  1 release partial     [....][bbbb][....][....]
>> //  2 release partial     [....][....][cccc][....]
>> //  3 release partial     [....][bbbb][cccc][....]
>> //  4 release partial     [....][..bb][cccc][....]
>> //  5 release partial     [....][bb..][cccc][....]
>> //  6 release partial     [....][bbbb][cc..][....]
>> //  7 release partial     [....][bbbb][..cc][....]
>> //  8 release partial     [....][..bb][cc..][....]
>> //  9 release partial     [....][bb..][..cc][....]
>> // 10 release partial     [....][bb..][cc..][....]
>> // 11 release partial     [....][..bb][..cc][....]
>> // 12 release partial     [....][.bb.][....][....]
>> // 13 release partial     [....][.bb.][.cc.][....]
>> 
>> 
>> Are we still missing any cases?
>> 
>> Did I add too much? (i.e. drop case 13?)
>
> Assuming that your letters mean the release range:
> - 1+2 are included in 3
> - 5, 7, 9, 10, 11, 13 are all not possible with one release call, since a single os::release_memory call taks a single contiguous release range
> - that leaves 3, 4, 6, 8. In other words:
> 
>    [stripe1][stripe2][strip3][stripe4]
> A           xxxxxxxxxxxxxxxxx
> B               xxxxxxxxxxxxx
> C           xxxxxxxxxxxxx
> D               xxxxxxxxx

I think I see 3 more cases for the release pattern that we can add:


  [aaaa][bbbb][cccc][dddd]

1 [....][xxxx][xxxx][....]
2 [....][..xx][xxxx][....]
3 [....][xxxx][xx..][....]
4 [....][..xx][xx..][....]

5 [....][..xx][....][....]
6 [....][....][xx..][....]
7 [....][.xx.][....][....]


Aren't cases 5,6 and 7 unique?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13813#discussion_r1187792475