TestG1OldAllocationPendingStackTrace.java run timeout because of can't trigger GC on some machine

[sendaoYan]

Describe the bug
TestG1OldAllocationPendingStackTrace.java run timeout because of can't trigger GC

To Reproduce
jtreg -va -nr -w tmp-temurin jdk/test/jdk/jfr/event/gc/stacktrace/TestG1OldAllocationPendingStackTrace.java &> temurin.log

Expected behavior
run pass on every machine.

Screenshots

Additional context
When I change -Xmx128M to -Xmx30M, this testcase run success.

temurin-manual-Xmx30M.log
temurin-manual-Xmx128M.log.zip
temurin.log

I have two machine run this testcase fail.

1. alios:
   

2. ubuntu 20.04
   

[sendaoYan]

Decrease the Xmx clould solve this problem:

[roberttoyonaga]

I tried reproducing this problem on x86_64 linux with JDK8, but was unable to after 5 iterations: https://ci.adoptium.net/view/Test_grinder/job/Grinder/8839/testReport/jdk_jfr_event_gc_stacktrace_TestG1OldAllocationPendingStackTrace/java/

I'm pretty confident this is a limitation with the JFR test, not the actual JDK/hotspot code. The test makes a best effort to trigger a GC by repeatedly doing allocations. A GC may be triggered by causes other than the test itself (this is undesired). If after 5 attempts, a GC due to the test allocations hasn't happened, the test fails).
https://github.com/openjdk/jdk8u/blob/master/jdk/test/jdk/jfr/event/gc/stacktrace/AllocationStackTrace.java#L389

I'm not sure what the best course of action is here. We could try to increase test allocation size or decrease heap size to increase the chances that a GC is caused by specific test code. I don't know how easy it would be to upstream this though considering I wasn't able to reproduce it.

[sophia-guo]

Rebuild with dragonwell jdk8 https://ci.adoptium.net/view/Test_grinder/job/Grinder/8867/console - TestG1OldAllocationPendingStackTrace passed.

As not reproducible we might just close this. Can reopen if happens again @sendaoYan ?