RFR: 8331185: Enable compiler memory limits in debug builds

[Thomas Stuefe]

On Fri, 26 Apr 2024 20:36:02 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> See [1] for previous discussions.
>> 
>> We'd like to introduce a default memory limit for compilations in debug builds. That way, we can catch pathological compiler errors that have an unreasonably high per-compilation memory footprint early during testing.
>> 
>> The default limit affects all compilations, unless the method is subject to a memory limit set from command line. Meaning, `-XX:CompileCommand=MemLimit,...` overrules the default.
>> 
>> Examples:
>> 
>> This lowers the memlimit for j.l.String methods - all methods will have the default 1GB limit in a debug JVM. Only j.l.String will run with a 100M limit: `-XX:CompileCommand=MemLimit,java.lang.String::*,100m`
>> 
>> This disables the default memlimit globally: `-XX:CompileCommand=MemLimit,*.*,0`
>> 
>> 
>> ---
>> 
>> The patch:
>> 
>> 1) adds a debug-only default memory limit of **1GB** (as proposed by @vnkozlov). The limit action is "crash", meaning we will assert.
>> 2) To test the mechanics, we now print out the memory limit for each compilation in the compilation cost record.
>> 3) Adapted and extended tests
>> 
>> I also fixed up some copyrights that I overlooked last year when adding the compiler memory statistics this patch builds atop of.
>> 
>> 
>> Tested:
>> 
>> - manually on Mac m1 (debug and release)
>> - GHAs are running
>> - but Oracle will do more testing before this goes in
>> 
>> [1] https://mail.openjdk.org/pipermail/hotspot-compiler-dev/2024-April/074787.html
>
> Closed test passed with `1200M` limit

@vnkozlov How do you want to handle this? Are these memory usage numbers pathological or normal?

Should I increase the general limit to 1200M? Alternatively, we can also just run failing the test with a higher memory limit.

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

PR Comment: https://git.openjdk.org/jdk/pull/18969#issuecomment-2080368042