RFR: 8335167: Test runtime/Thread/TestAlwaysPreTouchStacks.java failed with Expected a higher ratio between stack committed and reserved [v4]

[Thomas Stuefe]

On Fri, 13 Sep 2024 08:36:21 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The test program runs once with PreTouch and another without PreTouch stacks. For each run the amounts of reserved and committed stack regions are held and then compared the ratio of with and without PreTouch. The ratio of PreTouch test should be greater than the other (because there will be higher committed regions due to pre-touching the pages).
>> 
>> In other words, the old version of this test ran two tests: 1) `preTouchTest` and 2) `noPreTouchTest` and extracted the amount of reserved and committed memory for stack. The ratio of the committed to reserved for preTouchTest ($ratio = \frac{committed}{reserved}$) is expected to be high (>75%) and for the noPreTouchTest is expected to be small (<50%). These expected amounts are not robust for all cases and resulted in 8335167.
>> 
>> In this PR, only one test is run with two sets of options for preTouch and noPreTouch stack memory. The amount of reserved and committed are stored after each run and the ratio of two runs are compared. It is expected that the preTouch has a greater ratio than the noPreTouch (`preTouch.ratio > noPreTouch.ratio`). 
>> 
>> ### Tests
>> The specific test is run on linux-x64, windows-x64 and macosx-aarch64 in tiers1-5 (100+ times).
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed the place of calling reportDiagnosticSummary

@afshin-zafari This is good, and a lot more predictable.

But I would have liked a stronger check. 

Lets see if I understand this. NMT tells us the total amount of all thread stacks (test threads and other threads) as "Thread Stacks Reserved" and the touched portions of these threads as "Thread Stacks Committed" (mislabeled as committed, but that is a problem for another day). Right so far?

We create test threads with stacks with a total of 128MB, each thread is 8MB. So, 16 test threads. 

We (a) don't pretouch and (b) pretouch. (a) should use very little memory, otherwise something is wrong. (b) should use most of the stack, otherwise the Pretouch does not work.

A very safe bet is that the untouched stack (a) uses less than 1MB per stack. After all, the test threads don't do much and don't build up a deep stack. 1MB is *very* generous, it should be a lot less - if we were actually using 1MB, we would be in trouble. 

For (b), if pretouching stacks works, I would expect at least ~6MB of the 8MB of the thread stacks pretouched. I would expect more, actually, but lets go with 6MB. 

16 Threads. 16 * (6MB-1MB) = 80MB. So, I would expect an 80MB delta between no-pretouch and pretouch. If we don't see that, I would be curious as to why, because then pretouch may not work as expected.

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

PR Review: https://git.openjdk.org/jdk/pull/20531#pullrequestreview-2311738359