RFR: 8377347: jdk/jfr/event/gc/detailed/TestZAllocationStallEvent.java intermittent OOME

[SendaoYan]

On Tue, 10 Feb 2026 08:11:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>> Test test/jdk/jdk/jfr/event/gc/detailed/TestZAllocationStallEvent.java intermittent throw OOME on some specific mahcines. If I catch the OOM error wrapper the memory allocation loop, the Events.fromRecording still report OOM error. 
>> The max memory heap was seted to 32M, this seems too small for ZGC to workly normally on some specific machines, The gc log shows that ZGC unable to recliam the heap memory.
>> 
>> This PR change  include:
>> 
>> 1. the -Xmx seted to 64G
>> 2. increase the memory allocation loop count from 100 to 1000, this make sure the jfr evnet always happened. With the original count 100, the jfr event numbers couned to zero intermittely.
>> 3. Invoke whitebox.fullgc() explicitly, make sure the JFR check code has enough heap memory to finish.
>> 
>> The test jdk/jfr/event/gc/detailed/TestZAllocationStallEvent.java run 10k times all passed after this PR.
>
> test/jdk/jdk/jfr/event/gc/detailed/TestZAllocationStallEvent.java line 64:
> 
>> 62:             } catch (java.lang.OutOfMemoryError e) {
>> 63:                 System.gc();
>> 64:                 whitebox.fullGC();
> 
> Why manually invoking GC after OOM? Since we are not dropping refs to live-obj, I can't see that it will have any impact.
> 
> Do you encounter test failures without these two lines?

I was wondering the implicit GC after OOM does only free the young area. The intention of whitebox.fullgc is free the young and old heap. This is make sure there will enough free heap memory to continue the following test.

I will try to remove these two lines and run this test later, to verify that does these two lines are redunt.

Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29601#discussion_r2786519995