-
Bug
-
Resolution: Fixed
-
P2
-
11, 17, 21, 23, 24
-
b25
-
aarch64
-
Verified
The failure occurs when the register allocator must simultaneously spill a large number of values. More specifically, the failure happens because:
1. The matcher clones an address computation that is input to volatile loads, expecting the clones to later be subsumed into more complex load instructions. However, this subsumption never occurs because the machine loads require indirect memory and we end up with many duplicate values. See matcher-issue.png.
2. The scheduler excessively hoists the address computations (due to minuscule differences in block frequency), resulting in very long live ranges that live across a large number of new_array method calls. See scheduler-issue.png and note the hoisted addP_reg_imm nodes in B11 that should really schedule just before their respective loads/stores.
3. The register allocator must deal with extremely high register pressure in many places.
# Original description
Found by [~vnkozlov] when testing the upcoming 1GB default memory limit for compilations in Oracle's CI (https://github.com/openjdk/jdk/pull/18969).
He reported that when started with `-XX:CompileCommand=memlimit,*.*,1g~crash`, the test reaches the 1GB memory limit for its compilation. https://github.com/openjdk/jdk/pull/18969#issuecomment-2080024827
However, unlike the other memory limit break he reported for `compiler/c2/TestFindNode.java`, I was unable to reproduce the problem on my machines. Still, someone at Oracle should look at it.
Original Quote Vladimir:
compiler/loopopts/TestDeepGraphVerifyIterativeGVN.java failed on aarch64 when run with stress flags:
-XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:+StressArrayCopyMacroNode -XX:+StressLCM -XX:+StressGCM -XX:+StressIGVN -XX:+StressCCP -XX:+StressMacroExpansion -XX:+StressMethodHandleLinkerInlining -XX:+StressCompiledExceptionHandlers
# Internal Error (/workspace/open/src/hotspot/share/compiler/compilationMemoryStatistic.cpp:551), pid=912622, tid=912639
# fatal error: c2 compiler/c2/TestFindNode::test(()V): Hit MemLimit (limit: 1073741824 now: 1073824544)
V [libjvm.so+0x97496c] report_fatal(VMErrorType, char const*, int, char const*, ...)+0x108 (debug.cpp:214)
V [libjvm.so+0x8a9e2c] CompilationMemoryStatistic::on_arena_change(long, Arena const*)+0x5bc (compilationMemoryStatistic.cpp:551)
V [libjvm.so+0x58ee70] Arena::grow(unsigned long, AllocFailStrategy::AllocFailEnum)+0x10c (arena.cpp:300)
V [libjvm.so+0x13eb86c] PhaseChaitin::Split(unsigned int, ResourceArea*)+0x3ac (resourceArea.inline.hpp:35)
V [libjvm.so+0x798a44] PhaseChaitin::Register_Allocate()+0x554 (chaitin.cpp:553)
V [libjvm.so+0x8ced88] Compile::Code_Gen()+0x284 (compile.cpp:2988)
V [libjvm.so+0x8d1128] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1588 (compile.cpp:896)
V [libjvm.so+0x72d480] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x17c (c2compiler.cpp:142)
- relates to
-
JDK-8331283 [AArch64] C2: Register Allocator uses > 1GB in compiler/c2/TestFindNode.java
-
- Open
-
-
JDK-8344130 C2: Avoid excessive hoisting in scheduler due to minuscule differences in block frequency
-
- Resolved
-
-
JDK-8348658 [AArch64] The node limit in compiler/codegen/TestMatcherClone.java is too strict
-
- Resolved
-
-
JDK-8345306 C2: Investigate if the matcher unnecessarily clones indirect memory inputs on aarch64
-
- Open
-
-
JDK-8331185 Enable compiler memory limits in debug builds
-
- Resolved
-
-
JDK-8344018 Remove unlimited memory setting from TestScalarReplacementMaxLiveNodes
-
- Resolved
-
- links to
-
Commit(master) openjdk/jdk/7d4c3fd0
-
Review(master) openjdk/jdk/22157