JDK-8320909 : C2: Adapt IGVN's enqueuing logic to match idealization of AndNode with LShift operand
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 21,22,23
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2023-11-28
  • Updated: 2025-05-08
  • Resolved: 2025-04-24
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 25
25 b21Fixed
Related Reports
Blocks :  
JDK-8343131 - Add -XX:VerifyIterativeGVN=10 to CTW
Causes :  
JDK-8355492 - MissedOptCastII is missing UnlockDiagnosticVMOptions flag
Duplicate :  
JDK-8335866 - C2 compilation fails with "Missed optimization opportunity in PhaseIterGVN"
Relates :  
JDK-8298952 - All nodes should have type(n) == Value(n) after IGVN
Description
while java -XX:CompileCommand=quiet -XX:CompileCommand=compileonly,*Test*::* -XX:-TieredCompilation -Xcomp -XX:+StressIGVN -XX:VerifyIterativeGVN=10 Test.java; do :; done;

Missed Value optimization:
dist dump
---------------------------------------------
   1  272  Phi  === 523 88 34  [[ 386 550 276 376 319 366 548 408 410 571 ]]  #int:-4..0 !orig=[397] !jvms: Test::vMeth @ bci:85 (line 118)
   1  415  IfFalse  === 413  [[ 522 548 ]] #0 !orig=439 !jvms: Test::vMeth @ bci:143 (line 127)
   0  548  CastII  === 415 272  [[ 547 ]]  #int:-4..0 unconditional dependency
Current type:
int:-4..0
Optimized type:
int:-1

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (workspace/open/src/hotspot/share/opto/phaseX.cpp:1088), pid=1856529, tid=1856543
#  assert(!failure) failed: Missed optimization opportunity in PhaseIterGVN
#
# JRE version: Java(TM) SE Runtime Environment (22.0+26) (fastdebug build 22-ea+26-2075)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-ea+26-2075, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x1511dbd]  PhaseIterGVN::verify_optimize() [clone .part.0]+0x59d
Comments
Changeset: 6254046f Branch: master Author: Marc Chevalier <mchevalier@openjdk.org> Committer: Emanuel Peter <epeter@openjdk.org> Date: 2025-04-24 10:27:50 +0000 URL: https://git.openjdk.org/jdk/commit/6254046f508049a4e568f0f2eae51dc10da392c1
24-04-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/24792 Date: 2025-04-22 08:06:48 +0000
22-04-2025
Assigning this to myself, and letting this external contributor work on it: Kevin Stefanov<kevinstefanov15@gmail.com> Kevin said he unfortunately does not have time. I'll unassign it so anybody else can take this.
25-02-2025
And another one that might be related: JDK-8335866
08-07-2024
Thanks [~chagedorn]. I will double-check.
17-05-2024
I've attached another fuzzer failure (Test3.java): $ java -XX:CompileCommand=compileonly,*Test3*::* -XX:-TieredCompilation -Xcomp -XX:VerifyIterativeGVN=10 Test3.java This could have been traced back to JDK-8319793. However, a reduced version (Reduced3.java) $ java -XX:CompileCommand=compileonly,*Reduced*::* -XX:-TieredCompilation -Xcomp -XX:VerifyIterativeGVN=10 Reduced3.java could be traced way back to JDK 21 where VerifyIterativeGVN was changed. Maybe the reduction process reduced this to a different issue than originally present in Test3.java [~dlunden] Maybe you can double-check with both tests if a patch for this bug here will fix both tests.
17-05-2024
I've attached a reduced version of the newly found fuzzer issue: Reduced2.java $ java -XX:CompileOnly=Reduced2::test -XX:-TieredCompilation -Xbatch -XX:VerifyIterativeGVN=10 Reduced2.java Output: Missed Value optimization: dist dump --------------------------------------------- 1 212 ConvI2L === _ 131 [[ 213 ]] #long:minint..maxint:www !jvms: Reduced2::test @ bci:49 (line 21) 1 148 AddL === _ 75 147 [[ 213 149 75 184 194 174 247 ]] !orig=[246],... !jvms: Reduced2::test @ bci:36 (line 15) 0 213 AndL === _ 148 212 [[ 214 ]] !jvms: Reduced2::test @ bci:51 (line 21) Current type: long Optimized type: long:0 However, the reduced test looks different. I suspect it's a different issue. [~dlunden] once you have a fix for Test/TestSimple.java, can you also check if Reduced2.java still reproduces/is different? If so, please file a new bug.
14-05-2024
I attached a simplified test (TestSimple.java). Run with java -XX:CompileCommand=quiet -XX:CompileCommand=compileonly,*Test*::* -XX:-TieredCompilation -Xcomp -XX:VerifyIterativeGVN=10 TestSimple.java
28-11-2023
ILW = Same as JDK-8316361 / JDK-8318049 = P4
28-11-2023