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

[Afshin Zafari]

On Wed, 18 Sep 2024 06:23:22 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> 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.

@tstuefe, two cases added. Are they those you wanted?

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

PR Comment: https://git.openjdk.org/jdk/pull/20531#issuecomment-2358556638