RFR: 8366990: C2: Compilation hits the memory limit when verifying loop opts in Split-If code [v2]

[Benoît Maillard]

On Fri, 10 Oct 2025 15:04:36 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Benoît Maillard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add -XX:+UnlockDiagnosticVMOptions
>
> test/hotspot/jtreg/compiler/loopopts/TestVerifyLoopOptimizationsHitsMemLimit.java line 39:
> 
>> 37:  *      -XX:-TieredCompilation -Xcomp -XX:CompileCommand=dontinline,*::*
>> 38:  *      -XX:+StressLoopPeeling -XX:PerMethodTrapLimit=0 -XX:+VerifyLoopOptimizations
>> 39:  *      -XX:StressSeed=1870557292
> 
> I suggest to remove the stress seed since it might not trigger anymore in later builds. Usually, we add a run with a fixed stress seed and one without but since this test requires to do just some verification work, I would suggest to not add two runs but only one without fixed seed.
> 
> Another question: How close are we to hit the default the memory limit with this test? With your fix it probably consumes not much memory anymore. I therefore suggest to add  `MemLimit` as additional flag with a much smaller value to be sure that your fix works as expected (you might need to check how low we can choose the limit to not run into problems in higher tiers).

I was able to reduce the test further using a memory limit of 100M (approximately 10 times less than the default) and a shorter timeout with `creduce`. Compilation of the new `test` method with a fast debug build now takes an average of `1.22 s` over 100 runs according to `-XX:+CITime`.
With the decrease compilation time I think it now reasonable to have two runs (one with the stress seed, one without). Let me know if you think otherwise!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27731#discussion_r2431693355