RFR: 8358129: compiler/startup/StartupOutput.java runs into out of memory on Windows after JDK-8347406

[Damon Fenacci]

On Tue, 3 Jun 2025 09:57:37 GMT, SendaoYan <syan at openjdk.org> wrote:

>> The test `compiler/startup/StartupOutput.java` starts **200 VMs in a loop** , this can lead to resource shortages on some (Windows) machines.
>> 
>> There is no real need to run those VMs concurrently (their run is short and basically check that the VM doesn't crash giving limited code cache).
>> 
>> Running them **sequentially** should be OK and should avoid running out of memory.
>> 
>> Testing: Tier1-3+
>
> test/hotspot/jtreg/compiler/startup/StartupOutput.java line 67:
> 
>> 65:             int reservedCodeCacheSizeInKb = initialCodeCacheSizeInKb + rand.nextInt(200);
>> 66:             pb = ProcessTools.createLimitedTestJavaProcessBuilder("-XX:InitialCodeCacheSize=" + initialCodeCacheSizeInKb + "K", "-XX:ReservedCodeCacheSize=" + reservedCodeCacheSizeInKb + "k", "-version");
>> 67:             out = new OutputAnalyzer(pb.start());
> 
> SInce we  start VMs from concurrently to serially, do we need start VMs 200 times anymore, maybe 20 times or 5 times is enough, or even just 1 time is enough?

The goal is actually to test the VM startup with different (randomised) code cache sizes. So, I'm not sure that there is another way to do that other than starting a new VM every time. We could definitely try with a lower number but, as the whole test takes just a few seconds to run, I don't think it would make a big difference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25582#discussion_r2123709317