RFR: JDK-8305416: runtime/Thread/TestAlwaysPreTouchStacks.java failed with "Did not find expected NMT output" [v2]

[Thomas Stuefe]

On Tue, 25 Apr 2023 20:56:01 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8305416-runtime-Thread-TestAlwaysPreTouchStacks-fails
>>  - feedback david
>>  - Merge branch 'master' into JDK-8305416-runtime-Thread-TestAlwaysPreTouchStacks-fails
>>  - JDK-8305416-runtime-Thread-TestAlwaysPreTouchStacks-fails
>
> test/hotspot/jtreg/ProblemList.txt line 1:
> 
>> 1: #
> 
> Wouldn't it be simpler to rewrite this as a gtest and allocate using VM os::alloc() once then check that?

I'm not sure what you mean? This test tests that if I start a VM with `-XX:+AlwaysPreTouchThreadStacks` the VM will touch all - or most - of the thread stacks upon thread start. It exploits that NMT actually probes the thread stacks for committed pages, and checks what NMT says about thread stacks.

I would not know how to do this in gtest, espectially since forking is involved.

> test/hotspot/jtreg/runtime/Thread/TestAlwaysPreTouchStacks.java line 140:
> 
>> 138:                     long max_reserved = memoryCeilingMB * 3 * MB;
>> 139:                     long min_reserved = memoryCeilingMB * MB;
>> 140:                     if (reserved >= max_reserved || reserved < min_reserved) {
> 
> Why is `reserved >= max_reserved` a concern? Would we really want/need to look into this if it did happen?

I think so.

If we start x Threads, with stack size y, I expect to see not much more than x*y+(very generous fudge factor owed to unknown threads running). If I see more than that, NMT may be showing the wrong number for thread stacks, or scale the number wrong, see https://github.com/openjdk/jdk/pull/13665.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13295#discussion_r1178265421
PR Review Comment: https://git.openjdk.org/jdk/pull/13295#discussion_r1178262601