RFR: 8373945: vmTestbase eatMemory/ClassUnloader provoke OOME to force GC and might cause GC in other threads [v5]

[SendaoYan]

On Fri, 19 Dec 2025 18:11:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Increase max iteration for nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java line 50:
> 
>> 48:         "nsk.jvmti.CompiledMethodUnload.compmethunload001u";
>> 49: 
>> 50:     private final static int MAX_ITERATIONS = 50;
> 
> Can you explain the need for this change.

Test nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java always fails after this PR with the default value `MAX_ITERATIONS = 5`.

After I change the value of MAX_ITERATIONS to 50, The test always passed, and the test log shows that the number of unloaded enents is different every time.


Number of unloaded events 12 number of iterations 25
Number of unloaded events 1 number of iterations 36
Number of unloaded events 4 number of iterations 30


Before this PR, test call eatMemory to trigger full GC, this may need lots time. After this PR, test call `WhiteBox.getWhiteBox().fullGC()` to trigger full GC, this may be finish quickly.

This test get the unload event count through jni function, the unload event count was recorded by C++ `volatile` variable `class_unloaded`. It's not synchronized. So I think it's reasonable to increase the max count to catch the `volatile` variable change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28891#discussion_r2638907204