-
Bug
-
Resolution: Fixed
-
P2
-
7, 8, 11, 17, 21, 22
-
b22
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8323373 | 21.0.3-oracle | Aleksey Shipilev | P2 | Resolved | Fixed | b01 |
JDK-8319887 | 21.0.2 | Aleksey Shipilev | P2 | Closed | Fixed | b07 |
JDK-8321987 | 17.0.11-oracle | Tobias Hartmann | P2 | Closed | Fixed | b01 |
JDK-8322410 | 17.0.11 | Aleksey Shipilev | P2 | Resolved | Fixed | b01 |
JDK-8325015 | 11.0.24-oracle | Tobias Hartmann | P2 | Resolved | Fixed | b01 |
JDK-8329146 | 11.0.24 | Martin Balao Alonso | P2 | Resolved | Fixed | b01 |
JDK-8325739 | 11.0.23-oracle | Tobias Hartmann | P2 | Closed | Fixed | b04 |
JDK-8330446 | 11.0.23 | Martin Balao Alonso | P2 | Resolved | Fixed | b08 |
JDK-8329145 | openjdk8u422 | Martin Balao Alonso | P2 | Resolved | Fixed | b01 |
JDK-8330425 | openjdk8u412 | Martin Balao Alonso | P2 | Resolved | Fixed | b08 |
JDK-8325014 | 8u421 | Tobias Hartmann | P2 | Resolved | Fixed | b01 |
JDK-8325738 | 8u411 | Tobias Hartmann | P2 | Closed | Fixed | b06 |
JDK-8325016 | 7u431 | Tobias Hartmann | P2 | Resolved | Fixed | b01 |
JDK-8325740 | 7u421 | Tobias Hartmann | P2 | Closed | Fixed | b04 |
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (.../open/src/hotspot/share/opto/regalloc.hpp:85), pid=1681802, tid=1681816
# assert(idx < _node_regs_max_index) failed: Exceeded _node_regs array
#
# JRE version: Java(TM) SE Runtime Environment (22.0+17) (fastdebug build 22-ea+17-1342)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-ea+17-1342, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0x6ebf45] PhaseCFG::insert_goto_at(unsigned int, unsigned int)+0x695
Current CompileTask:
C2: 3200 109 b Test::vMeth (119 bytes)
Stack: [0x00007f12d5057000,0x00007f12d5158000], sp=0x00007f12d5153e90, free space=1011k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x6ebf45] PhaseCFG::insert_goto_at(unsigned int, unsigned int)+0x695 (regalloc.hpp:85)
V [libjvm.so+0x6ede8c] PhaseCFG::fixup_flow()+0x1ac
V [libjvm.so+0x9ee37d] Compile::Code_Gen()+0x4ad
V [libjvm.so+0x9f107e] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1c9e
...
FAILURE ANALYSIS
The failure is caused by a seemingly legal but degenerate Ideal graph where around 94% of the nodes (544 out of 579 after Compile::Optimize()) are floating-point additions (AddF). On x64, these nodes, whose second operand is `inc` (see attached TestSimpler.java), are initially implemented with addF_reg_reg machine nodes. Register allocation spills `inc`, and then PhaseChaitin::fixup_spills() replaces each of the addF_reg_reg machine nodes with their memory-operand version (addF_reg_mem). PhaseRegAlloc has allocated 1118 elements for PhaseRegAlloc::_node_regs (612 + (612 >> 1) + 200 as per PhaseRegAlloc::alloc_node_regs), but each transformation from addF_reg_reg to addF_reg_mem creates a fresh node ID (Compile::next_unique()) and Compile::_unique eventually grows beyond the size of PhaseRegAlloc::_node_regs, which finally triggers the assertion failure when PhaseRegAlloc::set_pair is called for a newly created node post-register allocation (e.g. during the target-dependent peephole phase).
The reason why this failure occurs only after
static float test(float inc) {
int i = 0, j = 0;
float f = dontInline();
while (i++ < 128) {
f += inc;
f += inc;
f += inc;
f += inc;
f += inc;
f += inc;
f += inc;
f += inc;
f += inc;
f += inc;
f += inc;
f += inc;
f += inc;
f += inc;
f += inc;
f += inc;
}
return f;
}
This stronger analysis result provided by
Potential solutions include:
- reusing the node ID of the replaced nodes in PhaseChaitin::fixup_spills() and/or adjusting Compile::_unique appropriately,
- resizing _node_regs on an out-of-bounds attempt (e.g. using a growable array),
- further increasing the size of _node_regs, and
- adjusting the loop unrolling policy to avoid excessive unrolling for pure reduction loops.
A temporary workaround is to use -XX:-UseCISCSpill.
- backported by
-
JDK-8322410 C2 compilation fails with "Exceeded _node_regs array"
- Resolved
-
JDK-8323373 C2 compilation fails with "Exceeded _node_regs array"
- Resolved
-
JDK-8325014 C2 compilation fails with "Exceeded _node_regs array"
- Resolved
-
JDK-8325015 C2 compilation fails with "Exceeded _node_regs array"
- Resolved
-
JDK-8325016 C2 compilation fails with "Exceeded _node_regs array"
- Resolved
-
JDK-8329145 C2 compilation fails with "Exceeded _node_regs array"
- Resolved
-
JDK-8329146 C2 compilation fails with "Exceeded _node_regs array"
- Resolved
-
JDK-8330425 C2 compilation fails with "Exceeded _node_regs array"
- Resolved
-
JDK-8330446 C2 compilation fails with "Exceeded _node_regs array"
- Resolved
-
JDK-8319887 C2 compilation fails with "Exceeded _node_regs array"
- Closed
-
JDK-8321987 C2 compilation fails with "Exceeded _node_regs array"
- Closed
-
JDK-8325738 C2 compilation fails with "Exceeded _node_regs array"
- Closed
-
JDK-8325739 C2 compilation fails with "Exceeded _node_regs array"
- Closed
-
JDK-8325740 C2 compilation fails with "Exceeded _node_regs array"
- Closed
- blocks
-
JDK-8319209 C2: make node_regs and scheduling data structures growable
- Open
- relates to
-
JDK-8287087 C2: perform SLP reduction analysis on-demand
- Resolved
-
JDK-8318959 C2: define MachNode::fill_new_machnode() statically
- Resolved
-
JDK-8318703 C2 SuperWord: take reduction nodes into account in early unrolling analysis
- Closed
- links to
-
Commit openjdk/jdk8u-dev/e72ea2d4
-
Commit openjdk/jdk11u-dev/d98b4607
-
Commit openjdk/jdk17u-dev/5ed19267
-
Commit openjdk/jdk21u/c9520790
-
Commit openjdk/jdk/a5818972
-
Review openjdk/jdk8u-dev/470
-
Review openjdk/jdk11u-dev/2617
-
Review openjdk/jdk17u-dev/2039
-
Review openjdk/jdk21u/317
-
Review openjdk/jdk/16306