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

[Thomas Stuefe]

On Tue, 9 May 2023 18:44:23 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>>> Aren't cases 5,6 and 7 unique?
>> 
>> Are they not already covered by existing tests? Since that functionality already exists?
>
> I might be missing it, but `grep -crn "release_memory(" test/hotspot/gtest` shows:
> 
> 
> test/hotspot/gtest/memory/test_virtualspace.cpp:2
> test/hotspot/gtest/runtime/test_os.cpp:20
> test/hotspot/gtest/runtime/test_committed_virtualmemory.cpp:1
> test/hotspot/gtest/nmt/test_nmt_locationprinting.cpp:1
> 
> 
> And when I look at the files I see:
> 
> `test/hotspot/gtest/runtime/test_os.cpp`
> - tests bad ranges on Windows
> - tests striped reserve, followed by one full release, one full re-reserve, then release again
> - tests os::print_memory_mappings()
> - tests os::win32::find_mapping()
> - tests `stripe-stripe-stripe-stripe-stripe-stripe` reserve, followed by `stripe-______-______-______-______-stripe` release, then re-reserve middle stripes, then full release
> 
> `test/hotspot/gtest/memory/test_virtualspace.cpp`
> - tests different sizes, alignments, one at a time
> 
> `test/hotspot/gtest/runtime/test_committed_virtualmemory.cpp`
> - tests whether the memory is resident
> 
> `test/hotspot/gtest/nmt/test_nmt_locationprinting.cpp`
> - tests NMT print_containing_region mechanism
> 
> So, no, I don't see dedicated partial release tests of single ranges.

You may be right, then. If you feel up for it, cases 5-7 would also be good to test. With the proposed setup, it would not be much more work. Thanks!

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

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