JDK-8331295 : C2: Do not clone address computations that are indirect memory input to at least one load/store
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,17,21,23,24
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • CPU: aarch64
  • Submitted: 2024-04-29
  • Updated: 2024-11-21
  • Resolved: 2024-11-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 24
24 b25Fixed
Related Reports
Relates :  
JDK-8331283 - [AArch64] C2: Register Allocator uses > 1GB in compiler/c2/TestFindNode.java
Relates :  
JDK-8344018 - Remove unlimited memory setting from TestScalarReplacementMaxLiveNodes
Relates :  
JDK-8331185 - Enable compiler memory limits in debug builds
Relates :  
JDK-8344130 - C2: Avoid excessive hoisting in scheduler due to minuscule differences in block frequency
Sub Tasks
JDK-8342612 :  
Increase memory usage of compiler/c2/TestScalarReplacementMaxLiveNodes.java - Resolved
Description
# Failure analysis

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)
Comments
Changeset: 7d4c3fd0 Branch: master Author: Daniel Lundén <dlunden@openjdk.org> Date: 2024-11-20 15:37:43 +0000 URL: https://git.openjdk.org/jdk/commit/7d4c3fd0915cfa8b279f42494625ec6afda338af
20-11-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/22157 Date: 2024-11-15 18:29:48 +0000
15-11-2024
FTR, the new failures that were now reported via JDK-8343038 are likely a regression from JDK-8340214. I verified that JDK-8324345 does not help.
25-10-2024
JDK-8342612 disabled the memory limit for test/hotspot/jtreg/compiler/c2/TestScalarReplacementMaxLiveNodes.java. That change should be reverted with the fix.
22-10-2024
GHA of jdk23u report the same failure by test compiler/c2/TestScalarReplacementMaxLiveNodes.java https://github.com/openjdk-bots/jdk23u/actions/runs/11399222312/job/31718806381 And I can reproduce the same failure with jdk23u fastdebug build locally.
18-10-2024
I'm attaching a smaller/simpler example that fails (based on TestFindNode.java). Investigating now, seems to be an issue with spill code generation. We choose to spill and rematerialize a number of live ranges, and subsequently all the new (very small) rematerialized live ranges also spill, resulting in extreme spill counts (=> extreme memory consumption).
07-10-2024
Repeating my comment from JDK-8337821 here so that it is not forgotten: "After fixing the (potential) issue, please remove the flag -XX:CompileCommand=MemLimit,*.*,0 from VectorReplicateLongSpecialImmTest.java."
06-08-2024
See also JDK-8337821.
06-08-2024
Another one with CTW: # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/workspace/open/src/hotspot/share/compiler/compilationMemoryStatistic.cpp:559), pid=262086, tid=262100 # fatal error: c2 com/zerog/ia/installer/IAStatusLog::<clinit>(()V): Hit MemLimit (limit: 1073741824 now: 1073771408) Current CompileTask: C2:86570 9900 b com.zerog.ia.installer.IAStatusLog::<clinit> (219 bytes) Stack: [0x0000ffff76c0b000,0x0000ffff76e09000], sp=0x0000ffff76e03650, free space=2017k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x167e0c4] VMError::report_and_die(int, char const*, char const*, std::__va_list, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x424 (compilationMemoryStatistic.cpp:559) V [libjvm.so+0x973edc] report_fatal(VMErrorType, char const*, int, char const*, ...)+0x108 (debug.cpp:214) V [libjvm.so+0x8a9360] CompilationMemoryStatistic::on_arena_change(long, Arena const*)+0x370 (compilationMemoryStatistic.cpp:559) V [libjvm.so+0x58d460] Arena::grow(unsigned long, AllocFailStrategy::AllocFailEnum)+0x10c (arena.cpp:299) V [libjvm.so+0x13f3904] PhaseChaitin::Split(unsigned int, ResourceArea*)+0x3c4 (resourceArea.inline.hpp:35) V [libjvm.so+0x7975f4] PhaseChaitin::Register_Allocate()+0x554 (chaitin.cpp:553) V [libjvm.so+0x8ce4a8] Compile::Code_Gen()+0x284 (compile.cpp:2983) V [libjvm.so+0x8d0834] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1540 (compile.cpp:886) V [libjvm.so+0x72cd00] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x17c (c2compiler.cpp:142) V [libjvm.so+0x8dc48c] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x7cc (compileBroker.cpp:2303) V [libjvm.so+0x8dcfd4] CompileBroker::compiler_thread_loop()+0x514 (compileBroker.cpp:1961) V [libjvm.so+0xd3faac] JavaThread::thread_main_inner()+0xcc (javaThread.cpp:759) V [libjvm.so+0x15a3960] Thread::call_run()+0xac (thread.cpp:225) V [libjvm.so+0x12fa384] thread_native_entry(Thread*)+0x130 (os_linux.cpp:846) C [libpthread.so.0+0x7950] start_thread+0x190
06-06-2024
similar crash occured on windows platform https://mach5.us.oracle.com/mdash/jobs/mach5-one-jdk-23+24-1954-tier9-20240522-2025-11095420?search=mach5-one-jdk-23%2B24-1954-tier9-20240522-2025-11095420-tier9-comp-Xcomp-jck_api_javax_swing-any-x64-debug-689 test result : https://mach5.us.oracle.com:10060/api/v1/results/mach5-one-jdk-23+24-1954-tier9-20240522-2025-11095420-tier9-comp-Xcomp-jck_api_javax_swing-any-x64-debug-689-1716416841-1441/log
23-05-2024
ILW = Excessive memory usage which might be expected, single test, no workaround = MLH = P4
30-04-2024
This test failure: # Internal Error (/workspace/open/src/hotspot/share/compiler/compilationMemoryStatistic.cpp:551), pid=2435878, tid=2435913 # fatal error: c2 compiler/loopopts/TestDeepGraphVerifyIterativeGVN::main(([Ljava/lang/String;)V): Hit MemLimit again (limit: 1073741824 now: 1073886384) # # JRE version: Java(TM) SE Runtime Environment (23.0) (fastdebug build 23-internal-2024-04-26-1717393.vladimir.kozlov.jdkgit2) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 23-internal-2024-04-26-1717393.vladimir.kozlov.jdkgit2, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) Current CompileTask: C2:54689 11 b compiler.loopopts.TestDeepGraphVerifyIterativeGVN::main (3529 bytes) Stack: [0x0000ffff607eb000,0x0000ffff609e9000], sp=0x0000ffff609e2cc0, free space=2015k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1676114] VMError::report_and_die(int, char const*, char const*, std::__va_list, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x424 (compilationMemoryStatistic.cpp:551) 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+0x153f6b4] Symbol::as_C_string() const+0x24 (symbol.cpp:140) V [libjvm.so+0x8a9bd0] CompilationMemoryStatistic::on_arena_change(long, Arena const*)+0x360 (compilationMemoryStatistic.cpp:162) 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)
29-04-2024