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

[Chris Plummer]

On Mon, 22 Dec 2025 08:44:39 GMT, SendaoYan <syan at openjdk.org> wrote:

>> 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 run 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.
>> 
>> Maybe that's why after this PR we need more try loop count to get the unload enent.
>> 
>> And if I add Thread.sleep(5000) after unloadClass() call  also make this test pass without change the value of MAX_ITERATIONS.
>> 
>> And I found that the vaule of MAX_ITERATIONS set to 50 seems do not enough. This will intermittent fails when run this test serially many times. So I change it to 500.
>
> Another solution is make some sleep after call `unloadClass()`
> 
> 
> diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java
> index 13058ec7864..15120d3cad6 100644
> --- a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java
> +++ b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java
> @@ -47,7 +47,7 @@ public class compmethunload001 {
>      private final static String CLS_TO_BE_UNLOADED =
>          "nsk.jvmti.CompiledMethodUnload.compmethunload001u";
>  
> -    private final static int MAX_ITERATIONS = 50;
> +    private final static int MAX_ITERATIONS = 5;
>  
>      static {
>          try {
> @@ -95,6 +95,7 @@ public static void callHotClass(String location) throws Exception {
>  
>          boolean clsUnloaded = clsUnLoader.unloadClass();
>          clsUnLoader = null;
> +        Thread.sleep(5000);
>          System.gc();
>      }

It seems this is somewhat poorly written test and is also somewhat imprecise and presumpive. I'm guessing the unload is delayed a bit because it happens async, and you can't really guess how long it is going to take for the unload to happen. The loop and the System.gc() calls are just passing time until the unload happens. The System.gc() calls should not be needed since the ClassUnloader.unloadClass() call should have been sufficient. I would suggest removing both System.gc() calls and just have a loop that does short sleeps until the unload happens. Maybe limit the loop to no more than 10 seconds. A more elegant approach would be to wait on a monitor for no more than 10 seconds, and have the native code notify the monitor when the unload happens.

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

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