RFR: JDK-8280940: gtest os.release_multi_mappings_vm is racy [v2]

[Kim Barrett]

On Wed, 9 Feb 2022 07:14:31 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi Kim,
>> 
>> thanks for taking a look!
>> 
>>> Not a review (I'm not an expert in the relevant area), just a couple drive-by comments. However, GitHub UI won't let me comment on the parts that I want. So getting as close as I can.
>>> 
>>> (1) The `TEST_VM` line should be outdented.
>> 
>> Sure.
>> 
>>> 
>>> (2) After 8277822, I think the tracking level is always going to be > `NMT_off` in a debug build, so we'll only be testing in product builds. That seems problematic.
>> 
>> We run the gtests in all NMT modes (off, summary, default), see:
>> 
>> https://github.com/openjdk/jdk/blob/072e7b4da0449ab7c1ab1ba0cfbb3db233823e7c/test/hotspot/jtreg/gtest/NMTGtests.java#L30-L36
>> 
>> so we run these tests in debug builds with NMT=off. The NMT gtests have been introduced with 8256844 and extended to cover the os* tests with 8277822.
>> 
>> That said, I should take a look at 8263464, see if this still is a problem.
>> 
>> Cheers, Thomas
>
> Okay, https://bugs.openjdk.java.net/browse/JDK-8263464 is still a problem. This means that even though we can release multiple mappings with os::release_memory, NMT cannot cope with that.
> 
> AFAIK the only real example of releasing multiple segments in one go is Windows + UseNUMA, and there os::release_memory(), when called over multiple segments, just recursively releases the segments individually. So I believe this works with NMT. Still, it would be nice to fix this.
> 
> @zhengyu123 : do you think https://bugs.openjdk.java.net/browse/JDK-8263464 is difficult to fix? Should I take a stab at it or do you want to take a look?

There used to not be a way to run gtests with non-default -XX:whatever
arguments and the like. But it looks like you did something about that in
JDK-8251158. I had no idea!

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

PR: https://git.openjdk.java.net/jdk/pull/7288