On Wed, 10 Dec 2025 14:33:28 GMT, Kevin Walls <[email protected]> wrote:
> This test has a number of issues, described in the note below.
(1)
OOM has been showing up in testing occasionally, possibly forever.
Eventually got a failure due to OOM, took many runs.
It's G1 hitting "GC Overhead Limit exceeded too often (5)".
Should set UseGCOverheadLimit false as this is something of a stress test.
Verbose log shows:
[10.495s][info][gc] GC Overhead Limit exceeded too often (5).
----------System.err:(6/249)----------
java.lang.OutOfMemoryError: Java heap space
(2)
-XX:+DisableExplicitGC would break this test, as noted in its comment, so do
not permit running with that option.
(3)
It can be too mysterious when tests print nothing about their work, unless they
fail. Are they even doing the work?
This test often (sometimes?) is not:
It eats memory, then does its validation only if stresser.continueExecution()
is true. This can be false and skip any testing.
So fix that with a do/while loop to ensure we validate at least once.
(4)
Then it failed immediately: nsk.share.TestFailure: collectionCount not
increased: 62 -> 62
It does not cope with iterations of the loop around the validation.
The only thing in validateNonTrivial() compared to the other validate() method,
is ensuring collection count does increase, and this fails.
It needs to do the eat memory or invoke gc before checking that, so put
eatMemory() inside the loop.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/28747#issuecomment-3637408913
