RFR: 8373022: Increase initial heap size for test which assumes no GC

[Chris Plummer]

On Wed, 3 Dec 2025 14:59:10 GMT, Joel Sikström <jsikstro at openjdk.org> wrote:

> Hello,
> 
>  If the initial heap size is set too low in the following tests a GC might run, which will interfere with the tests and migh cause them to fail. To solve this, we should run the tests with a bumped initial heap size so that the GC does not interfere.
>  
> Test originally failed when run with `-XX:InitialRAMPercentage=0`. We now explicitly set `-XX:InitialHeapSize=100M` and they now always pass.
> 
> Testing:
> * Rerun 10 times with Serial and Parallel for each test and they all pass

> > It's probably just the timing of the GC that determines whether the initial small heap is a problem or not. If you want the SA tests to be reliable with something like InitialRAMPercentage=0, probably all of the tests should be updated. However, personally I don't think this type of fix should be necessary unless you feel testing in the manner is something we want to support. There are plenty of tests that start failing when non-standard command line options are used.
> 
> FYI we just integrated a change that sets InitialRAMPercentage=0 for JDK 26 that we've been working on (see #28641). We've run up to Oracle's tier8 twice now, and apart from the tests that are included in this PR, we've not seen any other SA failures.
> 
> Of course there might be other intermittent failures in the future, in which case I see two approaches moving forward: problem listing or bumping the initial heap size for the affected tests, or going over all SA tests and making sure that they all run with a "large" initial heap size (like 100MB). Unless we start seing many (for some definition of many) test failures from now, a pragmatic compromise is to selectively bump the initial heap size of such tests, like I do in this PR.
> 
> Of course, the optimal approach would be to make any affected SA tests more robst to GC timings. But, since I'm not sure how much time we want to invest in improving SA tests, bumping the heap size is likely a good compromise here.

For the most part the SA tests are fine if there is a GC. The way they usually work is to launch the debuggee, wait for it to reach a stable point (all threads idle), and then start to query the debuggee. If a GC happens before reaching stability, that should be fine, and after stability we wouldn't expect any GCs no matter what the heap size is. There are some SA tests that run on active processes where GCs can happen, but they are written to allow for errors.

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

PR Comment: https://git.openjdk.org/jdk/pull/28637#issuecomment-3613332793