On Fri, 6 Mar 2026 02:16:08 GMT, Xiaohong Gong <[email protected]> wrote:
>> LGTM! Thanks for the update! > >> Hmm, what do @XiaohongGong @jatin-bhateja @iwanowww think about this? Where >> should we add the vector nodes to the worklist? What is the best design, so >> we can ensure IGVN always performs all the optimizations, no matter the >> inlining order? > > To me, it's better to trigger IGVN for all vector nodes after (1) the > compiler has finished incremental inlining for all APIs, and (2) all > `VectorBox`/`VectorUnbox` nodes have been cleaned up or expanded—perhaps at > the end of `PhaseVector::optimize_vector_boxes()`. At that point, the ideal > graph should be relatively clean, and we no longer need to worry about IR > optimizations being affected by edges from `VectorBox` nodes (an example: > [1]). > > As for when to add vector nodes to the worklist, I’m fine with doing that > during API inlining, as long as we can ensure that these nodes still exist by > the time `PhaseVector` completes. > > [1] > https://github.com/openjdk/jdk/pull/24674/changes/BASE..1b9c3b363fcc296956663249ef95d60a26a704d2#r2058061667 @XiaohongGong thanks for your insight! > As for when to add vector nodes to the worklist, I’m fine with doing that > during API inlining, as long as we can ensure that these nodes still exist by > the time PhaseVector completes. Between `inlining` and `PhaseVector`, there are several rounds of `igvn.optimize()` execution, for example: `remove_speculative_types(igvn)` and `cleanup_expensive_nodes(igvn)`, which will clear the igvn worklist. Therefore, it is unlikely that the vector nodes are added to the igvn worklist when it is inlined and then kept until after `PhaseVector` is executed. In addition, I found two new similar test failures: gc/shenandoah/mxbeans/TestChurnNotifications.java#aggressive gc/shenandoah/mxbeans/TestPauseNotifications.java#aggressive with options `-ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation -XX:VerifyIterativeGVN=1110`. Error log: Missed Identity optimization: Old node: dist dump --------------------------------------------- 1 1882 DecodeN === _ 3098 [[ 1883 1884 2262 2260 ]] #instptr:java/util/TreeMap$Entry (java/util/Map$Entry):BotPTR:exact+0,iid=bot Oop:instptr:java/util/TreeMap$Entry (java/util/Map$Entry):BotPTR:exact+0,iid=bot !orig=[2240] !jvms: TreeMap$PrivateEntryIterator::nextEntry @ bci:1 (line 1518) TreeMap$KeyIterator::next @ bci:1 (line 1576) Collections$UnmodifiableCollection$1::next @ bci:4 (line 1082) CompositeDataSupport::<init> @ bci:145 (line 224) 0 1883 ShenandoahLoadReferenceBarrier === _ 1882 [[ 1891 1891 2039 2160 2150 2209 2140 2072 2120 1953 2130 1999 2009 2019 2029 ]] Oop:instptr:java/util/TreeMap$Entry (java/util/Map$Entry):BotPTR:exact+0,iid=bot !jvms: TreeMap$PrivateEntryIterator::nextEntry @ bci:1 (line 1518) TreeMap$KeyIterator::next @ bci:1 (line 1576) Collections$UnmodifiableCollection$1::next @ bci:4 (line 1082) CompositeDataSupport::<init> @ bci:145 (line 224) New node: dist dump --------------------------------------------- 1 3098 Phi === 2992 1538 2276 [[ 1882 ]] #narrowoop: instptr:java/util/TreeMap$Entry (java/util/Map$Entry):BotPTR:exact+0,iid=bot !orig=[2239] !jvms: TreeMap$PrivateEntryIterator::nextEntry @ bci:44 (line 1523) TreeMap$KeyIterator::next @ bci:1 (line 1576) Collections$UnmodifiableCollection$1::next @ bci:4 (line 1082) CompositeDataSupport::<init> @ bci:145 (line 224) 0 1882 DecodeN === _ 3098 [[ 1883 1884 2262 2260 ]] #instptr:java/util/TreeMap$Entry (java/util/Map$Entry):BotPTR:exact+0,iid=bot Oop:instptr:java/util/TreeMap$Entry (java/util/Map$Entry):BotPTR:exact+0,iid=bot !orig=[2240] !jvms: TreeMap$PrivateEntryIterator::nextEntry @ bci:1 (line 1518) TreeMap$KeyIterator::next @ bci:1 (line 1576) Collections$UnmodifiableCollection$1::next @ bci:4 (line 1082) CompositeDataSupport::<init> @ bci:145 (line 224) # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/tmp/ci-scripts/jdk-src/src/hotspot/share/opto/phaseX.cpp:2101), pid=522240, tid=522604 # assert(false) failed: Missed Identity optimization opportunity in PhaseIterGVN for ShenandoahLoadReferenceBarrier # # JRE version: OpenJDK Runtime Environment (27.0) (fastdebug build 27-internal-git-4386e9ca43b) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 27-internal-git-4386e9ca43b, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, shenandoah gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x18f6aa5] PhaseIterGVN::verify_Identity_for(Node*)+0x2d5 # # Core dump will be written. Default location: Determined by the following: "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -F%F -- %E" (alternatively, falling back to /tmp/ci-scripts/jtwork/hotspot/scratch/22/core.522240) # # An error report file with more information is saved as: # /tmp/ci-scripts/jtwork/hotspot/scratch/22/hs_err_pid522240.log [thread 522682 also had an error] # # Compiler replay data is saved as: # /tmp/ci-scripts/jtwork/hotspot/scratch/22/replay_pid522240.log # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp ``` `ShenandoahLoadReferenceBarrier` is not a vector node, so I tried adding **all** nodes to the worklist after `PhaseVector`, but it still didn't fix the issue. Therefore, I think this missing identity optimization was reported in an earlier phase. So I'd like to say that adding all (or vector) nodes to the igvn worklist after the `PhaseVector` phase only partially solves the problem, but it does solve a large part of it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28313#issuecomment-4009279114
