RFR: 8327963: C2: fix construction of memory graph around Initialize node to prevent incorrect execution if allocation is removed [v8]

Roland Westrelin roland at openjdk.org
Fri Jun 6 09:05:54 UTC 2025


On Thu, 5 Jun 2025 12:07:01 GMT, Roberto Castañeda Lozano <rcastanedalo at openjdk.org> wrote:

> > Thanks, will run some testing and come back with the results.
> 
> `compiler/c2/TestVerifyIterativeGVN.java` fails as follows (I tested the PR applied on top of jdk-25+25 but I see the failure also in the [GHA results](https://github.com/rwestrel/jdk/actions/runs/15438508506/job/43452592735)):
> 
> ```
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/home/rocastan/git/views/JDK-8327963-memprojs/open/src/hotspot/share/opto/node.hpp:457), pid=464370, tid=464390
> #  assert(is_not_dead(n)) failed: can not use dead node
> #
> (...)
> Current CompileTask:
> C2:128    9    b  4       java.lang.reflect.ClassFileFormatVersion::<clinit> (417 bytes)
> 
> Stack: [0x000070ba24200000,0x000070ba24300000],  sp=0x000070ba242fae70,  free space=1003k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x519ad1]  Node::set_req(unsigned int, Node*)+0x251  (node.hpp:457)
> V  [libjvm.so+0x17d2d99]  PhaseIterGVN::subsume_node(Node*, Node*)+0x239  (phaseX.cpp:1425)
> V  [libjvm.so+0x15feaf4]  InitializeNode::replace_mem_projs_by(Node*, PhaseIterGVN*)+0x1d4  (phaseX.hpp:539)
> V  [libjvm.so+0x1532cd7]  PhaseMacroExpand::expand_allocate_common(AllocateNode*, Node*, TypeFunc const*, unsigned char*, Node*)+0x167  (macro.cpp:1316)
> V  [libjvm.so+0x153e92e]  PhaseMacroExpand::expand_macro_nodes()+0xc5e  (macro.cpp:2687)
> V  [libjvm.so+0xb286e7]  Compile::Optimize()+0xe37  (compile.cpp:2533)
> (...)
> ```

Thanks for the report. Should be fixed in new commit. The logic I used to remove `NarrowMemProj`s was a bit of a hack. I replaced it by code that's a bit longer but also robuster. On that topic: removal `NarrowMemProj`s happens during macro expansion. There are rare cases where C2 can't go from the `Allocate` to the `Initialize` because the IR graph doesn't match the expected pattern (some transformation introduced a region in between). In that case,  `NarrowMemProj`s are not removed. That seems reasonable as there's no requirement to remove them and guaranteeing they are always removed would require a bit more code AFAICT.

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

PR Comment: https://git.openjdk.org/jdk/pull/24570#issuecomment-2948580536


More information about the hotspot-compiler-dev mailing list