Bug ID: JDK-8367967 C2: "fatal error: Not monotonic" with Mod nodes

JDK-8367967 : C2: "fatal error: Not monotonic" with Mod nodes

Type: Bug
Component: hotspot
Sub-Component: compiler
Affected Version: 26

Priority: P3
Status: Open
Resolution: Unresolved

Submitted: 2025-09-18
Updated: 2025-09-28

Versions (Unresolved/Resolved/Fixed)

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 26
26Unresolved

Related Reports

Causes :

JDK-8356813 - Improve Mod(I|L)Node::Value

Description

Since yesterday we see the following error on Linux aarch64 . Is it maybe related to new HS coding?
Test java/foreign/TestUpcallStress.java triggers this (fastdebug was used for running tests) .

# Internal Error (/priv/jenkins/client-home/workspace/openjdk-jdk-dev-linux_aarch64-dbg/jdk/src/hotspot/share/opto/phaseX.cpp:2763), pid=1089937, tid=1089972
# fatal error: Not monotonic
#
# JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.sapmachine.jdk)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.sapmachine.jdk, mixed mode, sharing, tiered, compressed oops, compact obj headers, g1 gc, linux-aarch64)
# Problematic frame:
# V [libjvm.so+0x157a6c4] PhaseCCP::verify_type(Node*, Type const*, Type const*)+0x1a4
#
#
--------------- T H R E A D ---------------

Current thread (0x0000ff5b2024d160): JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=1089972, stack(0x0000ff5aeec08000,0x0000ff5aeee06000) (2040K)]


Current CompileTask:
C2:21575 3680 4 jdk.internal.foreign.Utils::computePaddedStructLayout (159 bytes)

Stack: [0x0000ff5aeec08000,0x0000ff5aeee06000], sp=0x0000ff5aeee009e0, free space=2018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x157a6c4] PhaseCCP::verify_type(Node*, Type const*, Type const*)+0x1a4 (phaseX.cpp:2763)
V [libjvm.so+0x15829bc] PhaseCCP::analyze()+0x2bc (phaseX.cpp:2806)
V [libjvm.so+0x996868] Compile::Optimize()+0x768 (compile.cpp:2481)
V [libjvm.so+0x999084] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1664 (compile.cpp:859)
V [libjvm.so+0x7dd3dc] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x2c8 (c2compiler.cpp:147)
V [libjvm.so+0x9a7bf8] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xaa4 (compileBroker.cpp:2342)
V [libjvm.so+0x9a8974] CompileBroker::compiler_thread_loop()+0x600 (compileBroker.cpp:1986)
V [libjvm.so+0xeb23f8] JavaThread::thread_main_inner()+0x104 (javaThread.cpp:775)
V [libjvm.so+0x19b54fc] Thread::call_run()+0xac (thread.cpp:243)
V [libjvm.so+0x14faa14] thread_native_entry(Thread*)+0x130 (os_linux.cpp:898)
C [libc.so.6+0x8595c]

Comments

We are seeing this failure a lot in our CI.
28-09-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/27408 Date: 2025-09-21 06:11:11 +0000
21-09-2025
See my comment here https://github.com/openjdk/jdk/pull/25254/files#r2362960218
19-09-2025
[~hgreule] I assigned the bug to you, so you can move forward with your fix.
19-09-2025
ILW = CCP is not monotonic, intermittent, disable compilation of affected method = HLM = P3
19-09-2025
Thanks [~mbaesken] for the report and providing more logs and [~hgreule] for closer analyzing the problem! I think that is indeed the problem. Based on your analysis, I quickly played around with some test and could reproduce the issue for ModI/L with -XX:+StressCCP on linux-x64-debug: $ java -XX:CompileOnly=Test::test* -XX:+StressCCP -XX:RepeatCompilation=100 -Xcomp Test.java 124 Phi === 36 102 20 [[ 139 152 ]] #int:0..34 !jvms: Test::testInt @ bci:8 (line 16) 138 Phi === 136 137 20 [[ 147 152 ]] #int:0..3 !jvms: Test::testInt @ bci:32 (line 19) 144 IfTrue === 143 [[ 157 152 155 ]] #1 !jvms: Test::testInt @ bci:35 (line 20) 152 ModI === 144 138 124 [[ 155 ]] !jvms: Test::testInt @ bci:35 (line 20) told = int:0 tnew = top 125 Phi === 37 103 20 [[ 140 153 ]] #long:0..34 !jvms: Test::testLong @ bci:8 (line 27) 139 Phi === 137 138 20 [[ 148 153 ]] #long:0..3 !jvms: Test::testLong @ bci:35 (line 30) 145 IfTrue === 144 [[ 158 153 156 ]] #1 !jvms: Test::testLong @ bci:38 (line 31) 153 ModL === 145 139 125 [[ 156 ]] !jvms: Test::testLong @ bci:38 (line 31) told = long:0 tnew = top I attached the test to this bug. You can use it as a regression test :-)
19-09-2025
Btw. all of our test-runs showing this issue "# fatal error: Not monotonic" generate a replay - file of 0 bytes size . This is of course not very useful. Do you think this is expected for some reason in this case? Or is it another bug ?
19-09-2025
[~chagedorn] why the 0-byte / empty replay files for those errors ?
19-09-2025
Thanks, I think I understand what's going wrong: We first see the ModL with input types long:0 and long:0. We calculate the resulting type long:0 here https://github.com/openjdk/jdk/blob/c7f014ed494409cdf9fc925fe98de08346606408/src/hotspot/share/opto/divnode.cpp#L1211 But then, we see the same ModL with a wider dividend but still with the long:0 divisor, in which case we hit the case a few lines below https://github.com/openjdk/jdk/blob/c7f014ed494409cdf9fc925fe98de08346606408/src/hotspot/share/opto/divnode.cpp#L1219 => we produce a top result type. Moving the check returning top above the one returning 0 should fix that. I'm not sure how an isolated test case for that would look like, any ideas there are welcome :)
18-09-2025
> I wasn't able to reproduce this crash so far. I had to run the whole jdk :tier4 (fastdebug binaries) but with -avm -conc:15 to see the issue. With the 'usual' -conc:4 I use in my own local runs, I did not see it . With -conc:15 (this is what we use in our central tests) we see it often (always?).
18-09-2025
Yes we have this in the jtr : ----------System.out:(54/5024)---------- NativeTestHelper::DEFAULT_RANDOM.seed = 1393286683 Re-run with '-DNativeTestHelper.DEFAULT_RANDOM.seed=1393286683' to reproduce test TestUpcallStress.testUpcallsStress(0, "f0_V__", VOID, [], []): success [129ms] test TestUpcallStress.testUpcallsStress(17, "f0_V_S_DI", VOID, [STRUCT], [DOUBLE, INT]): success [49ms] test TestUpcallStress.testUpcallsStress(34, "f0_V_S_IDF", VOID, [STRUCT], [INT, DOUBLE, FLOAT]): success [97ms] test TestUpcallStress.testUpcallsStress(51, "f0_V_S_FDD", VOID, [STRUCT], [FLOAT, DOUBLE, DOUBLE]): success [81ms] test TestUpcallStress.testUpcallsStress(68, "f0_V_S_DDP", VOID, [STRUCT], [DOUBLE, DOUBLE, POINTER]): success [54ms] test TestUpcallStress.testUpcallsStress(85, "f0_V_S_PPI", VOID, [STRUCT], [POINTER, POINTER, INT]): success [53ms] test TestUpcallStress.testUpcallsStress(102, "f0_V_IS_FF", VOID, [INT, STRUCT], [FLOAT, FLOAT]): success [94ms] test TestUpcallStress.testUpcallsStress(119, "f0_V_IS_IFD", VOID, [INT, STRUCT], [INT, FLOAT, DOUBLE]): success [487ms] test TestUpcallStress.testUpcallsStress(136, "f0_V_IS_FFP", VOID, [INT, STRUCT], [FLOAT, FLOAT, POINTER]): success [218ms] test TestUpcallStress.testUpcallsStress(153, "f0_V_IS_DDI", VOID, [INT, STRUCT], [DOUBLE, DOUBLE, INT]): success [149ms] test TestUpcallStress.testUpcallsStress(170, "f0_V_IS_PDF", VOID, [INT, STRUCT], [POINTER, DOUBLE, FLOAT]): success [2476ms] test TestUpcallStress.testUpcallsStress(187, "f0_V_FS_ID", VOID, [FLOAT, STRUCT], [INT, DOUBLE]): success [3863ms] test TestUpcallStress.testUpcallsStress(204, "f0_V_FS_IIP", VOID, [FLOAT, STRUCT], [INT, INT, POINTER]): success [127ms] test TestUpcallStress.testUpcallsStress(221, "f0_V_FS_FFI", VOID, [FLOAT, STRUCT], [FLOAT, FLOAT, INT]): success [214ms] test TestUpcallStress.testUpcallsStress(238, "f0_V_FS_DFF", VOID, [FLOAT, STRUCT], [DOUBLE, FLOAT, FLOAT]): success [7360ms] test TestUpcallStress.testUpcallsStress(255, "f0_V_FS_PFD", VOID, [FLOAT, STRUCT], [POINTER, FLOAT, DOUBLE]): success [2518ms] test TestUpcallStress.testUpcallsStress(272, "f0_V_DS_P", VOID, [DOUBLE, STRUCT], [POINTER]): success [69ms] test TestUpcallStress.testUpcallsStress(289, "f0_V_DS_III", VOID, [DOUBLE, STRUCT], [INT, INT, INT]): success [30ms] test TestUpcallStress.testUpcallsStress(306, "f0_V_DS_FIF", VOID, [DOUBLE, STRUCT], [FLOAT, INT, FLOAT]): success [80ms] test TestUpcallStress.testUpcallsStress(323, "f0_V_DS_DID", VOID, [DOUBLE, STRUCT], [DOUBLE, INT, DOUBLE]): success [135ms] 1273 Phi === 890 185 335 [[ 897 1274 1611 2150 ]] #long !jvms: Utils::computePaddedStructLayout @ bci:28 (line 286) 496 Phi === 890 183 335 [[ 2036 1274 249 2150 ]] #long !orig=3014,[499] !jvms: Utils::computePaddedStructLayout @ bci:28 (line 286) 1268 IfTrue === 1615 [[ 896 1274 ]] #1 !orig=[3010],[1266] !jvms: Utils::computePadding @ bci:11 (line 267) Utils::computePaddedStructLayout @ bci:117 (line 296) 1274 ModL === 1268 496 1273 [[ 897 ]] !jvms: Utils::computePadding @ bci:30 (line 271) Utils::computePaddedStructLayout @ bci:117 (line 296) told = long:0 tnew = top # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/priv/jenkins/client-home/workspace/openjdk-jdk-dev-linux_aarch64-dbg/jdk/src/hotspot/share/opto/phaseX.cpp:2763), pid=513543, tid=513639 # fatal error: Not monotonic # # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.sapmachine.jdk) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.sapmachine.jdk, mixed mode, sharing, tiered, compressed oops, compact obj headers, g1 gc, linux-aarch64) # Problematic frame: # V [libjvm.so+0x15798d4] PhaseCCP::verify_type(Node, Type const, Type const*)+0x1a4 # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /priv/jvmtests/output_openjdk26_dev_dbgU_linuxaarch64/jtreg_jdk_tier4_work/JTwork/scratch/5/core.513543) # # An error report file with more information is saved as: # /priv/jvmtests/output_openjdk26_dev_dbgU_linuxaarch64/jtreg_jdk_tier4_work/JTwork/scratch/5/hs_err_pid513543.log test TestUpcallStress.testUpcallsStress(340, "f0_V_DS_PIP", VOID, [DOUBLE, STRUCT], [POINTER, INT, POINTER]): success [3476ms] test TestUpcallStress.testUpcallsStress(357, "f0_V_PS_I", VOID, [POINTER, STRUCT], [INT]): success [41ms] test TestUpcallStress.testUpcallsStress(374, "f0_V_PS_PF", VOID, [POINTER, STRUCT], [POINTER, FLOAT]): success [2818ms] test TestUpcallStress.testUpcallsStress(391, "f0_V_PS_IPD", VOID, [POINTER, STRUCT], [INT, POINTER, DOUBLE]): success [42ms] test TestUpcallStress.testUpcallsStress(408, "f0_V_PS_FPP", VOID, [POINTER, STRUCT], [FLOAT, POINTER, POINTER]): success [118ms] test TestUpcallStress.testUpcallsStress(425, "f0_V_PS_PII", VOID, [POINTER, STRUCT], [POINTER, INT, INT]): success [82ms] [thread 513987 also had an error][thread 513724 also had an error]
18-09-2025
I wasn't able to reproduce this crash so far. Do you have more detailed logs? PhaseCCP::verify_type should print "told = " and "tnew = " as well as the node information, which would provide some better insight what's going on.
18-09-2025