JDK-8371146 : C2 SuperWord: VTransform::add_speculative_check uses pre_init that is pinned after Auto_Vectorization_Check, leading to bad graph
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 26
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-11-03
  • Updated: 2025-11-28
  • Resolved: 2025-11-26
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
26 b26Fixed
Related Reports
Causes :  
JDK-8372685 - C2 SuperWord: wrong requires in test after JDK-8371146
Causes :  
JDK-8372751 - [TESTBUG] @requires vm.gc == "ZGC" doesn't work
Causes :  
JDK-8324751 - C2 SuperWord: Aliasing Analysis runtime check
Relates :  
JDK-8372613 - C2 SuperWord: we set incorrect ctrl for some nodes, needs verification
Description
It looks like a regression from JDK-8324751, where we add aliasing runtime checks.

VTransform::add_speculative_check
Inserts a runtime check before at the ParsePredicate that is before the pre-loop. For this, it requires the pre_init value, which is available before the pre loop. In most cases, it is also already available before the ParsePredicate, but in rare cases that assumption does not hold. In the fuzzer case, there is a CastII pinning the pre_init value after the ParsePredicate for the auto vectorization check. If we use that value and insert a runtime check before the ParsePredicate, then that leads to a circular graph, hence a "bad graph" assert.
See also the attached images below, especially img2 and img3.

Solution Idea:
We may have to improve our checks, and not just check that the values we use are pre-loop independent, but also available before the ParsePredicate for the Auto_Vectorization_Check.

We need to look at places like:
VPointer::can_make_speculative_aliasing_check_with

--------------------- Original Report -----------------------

java -XX:CompileCommand=quiet -XX:CompileCommand=compileonly,Test::mainTest -XX:RepeatCompilation=100 -XX:-TieredCompilation -Xcomp -XX:+StressLoopPeeling Test.java

Bad graph detected in build_loop_late
n:  5762  Bool  === _ 5761  [[ 5713 ]] [ne]
early(n):  1897  IfTrue  === 1896  [[ 2445 2584 2464 2607 2458 2456 2452 2450 ]] #1 !orig=[2482],950 !jvms: Test::mainTest @ bci:125 (line 137)
n->in(1):  5761  CmpI  === _ 5760 38  [[ 5762 ]] 
early(n->in(1)):  1897  IfTrue  === 1896  [[ 2445 2584 2464 2607 2458 2456 2452 2450 ]] #1 !orig=[2482],950 !jvms: Test::mainTest @ bci:125 (line 137)
n->in(1)->in(1):  5760  OrI  === _ 5813 5815  [[ 5761 ]] 
early(n->in(1)->in(1)):  1897  IfTrue  === 1896  [[ 2445 2584 2464 2607 2458 2456 2452 2450 ]] #1 !orig=[2482],950 !jvms: Test::mainTest @ bci:125 (line 137)
n->in(1)->in(2):    38  ConI  === 0  [[ 57 93 1667 190 1431 765 513 146 146 157 157 168 168 179 179 190 503 493 1783 350 483 473 1444 310 310 320 320 330 330 340 340 350 1385 1396 1427 1440 1868 1323 606 616 1869 626 566 636 2265 1218 1239 1254 1203 1869 3119 1431 5761 5813 5815 5695 5808 5806 5235 ]]  #int:0
early(n->in(1)->in(2)):     0  Root  === 0 150 161 172 183 194 1207 314 324 334 344 354 5521 477 487 497 507 517 610 620 630 640 2565 3067 1328 3141 1327 1243 1258 2520 3220 5510 1222 3056 3045 3187 4933 2542 2366 3175 2127 2139 2150 2161 2173 2184 2195 2206 2287 2587 4922 2321 2333 4623 4955 2988 3000 3011 3022 3034 4096 4601 4944 4134 4448 4459  [[ 0 1 3 22 1318 24 25 26 27 28 29 1292 31 32 33 1169 36 38 1151 40 1135 42 2654 46 1034 1032 930 53 866 858 81 848 85 846 89 1322 124 145 156 167 178 189 2637 232 255 271 272 287 821 782 779 454 455 456 459 461 773 556 762 593 736 735 2628 2023 2021 1693 1600 1457 1584 1477 1464 2723 2791 2840 2841 3378 3379 3407 3408 3409 3411 3412 3413 3425 3434 3437 3438 3453 3454 3455 4066 4074 4081 4139 4140 4142 4153 4170 4183 4184 4336 4437 4638 4685 4695 4698 4700 4710 4712 4961 4972 4978 5318 5634 5771 5787 5788 5790 5823 5825 5837 5840 5842 5847 5852 ]] 

LCA(n):  1905  IfTrue  === 1904  [[ 5713 5733 ]] #1
n->out(0):  5713  If  === 1905 5762  [[ 5714 5715 ]] P=0.999999, C=-1.000000
n->out(0)->out(0):  5714  IfTrue  === 5713  [[ 1896 ]] #1
n->out(0)->out(1):  5715  IfFalse  === 5713  [[ 1894 ]] #0

idoms of early "1897 IfTrue":
idom[3]:   1905  IfTrue
idom[2]:   5713  If
idom[1]:   5714  IfTrue
idom[0]:   1896  ParsePredicate
n:         1897  IfTrue

idoms of (wrong) LCA "1905 IfTrue":
n:         1905  IfTrue

Real LCA of early "1897 IfTrue" (idom[3]) and wrong LCA "1905 IfTrue":
 1905  IfTrue  === 1904  [[ 5713 5733 ]] #1

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (workspace/open/src/hotspot/share/opto/loopnode.cpp:6851), pid=3656089, tid=3656108
#  assert(false) failed: Bad graph detected in build_loop_late
#
# JRE version: Java(TM) SE Runtime Environment (26.0+23) (fastdebug build 26-ea+23-2304)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 26-ea+23-2304, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# V  [libjvm.so+0x1322d28]  PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x888

Current CompileTask:
C2:185    5   !b        Test::mainTest (650 bytes)

Stack: [0x0000ffff89bf4000,0x0000ffff89df2000],  sp=0x0000ffff89dec4f0,  free space=2017k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1322d28]  PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x888  (loopnode.cpp:6851)
V  [libjvm.so+0x1322f08]  PhaseIdealLoop::build_loop_late(VectorSet&, Node_List&, Node_Stack&)+0x19c  (loopnode.cpp:6718)
V  [libjvm.so+0x1323770]  PhaseIdealLoop::build_and_optimize()+0x610  (loopnode.cpp:5111)
V  [libjvm.so+0x9c64e0]  PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x340  (loopnode.hpp:1233)
V  [libjvm.so+0x9be9e8]  Compile::optimize_loops(PhaseIterGVN&, LoopOptsMode)+0x88  (compile.cpp:2262)
V  [libjvm.so+0x9c0e78]  Compile::Optimize()+0xa70  (compile.cpp:2511)
V  [libjvm.so+0x9c3450]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x16a4  (compile.cpp:860)
V  [libjvm.so+0x7ee880]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x2dc  (c2compiler.cpp:147)
V  [libjvm.so+0x9d216c]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xb08  (compileBroker.cpp:2345)
V  [libjvm.so+0x9d3098]  CompileBroker::compiler_thread_loop()+0x638  (compileBroker.cpp:1989)
V  [libjvm.so+0xed4268]  JavaThread::thread_main_inner()+0x108  (javaThread.cpp:771)
V  [libjvm.so+0x184a73c]  Thread::call_run()+0xac  (thread.cpp:243)
V  [libjvm.so+0x15288fc]  thread_native_entry(Thread*)+0x12c  (os_linux.cpp:883)
C  [libc.so.6+0x80b50]  start_thread+0x300
Comments
Our failing Windows tests were executed on Windows Server 2016 . But the MS docu https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc2 claims that VirtualAlloc2 is supported there ? Is the MS docu wrong ? (unfortunately 'ZGC requires Windows version 1803 or later' mentions only the Win10 version)
27-11-2025
> I suspect this patch would do the trick, I'll file and link a bug for it: This looks reasonable to me; if you have a PR I can put it into our build/test queue.
27-11-2025
[~mbaesken] I suspect this patch would do the trick, I'll file and link a bug for it: diff --git a/test/hotspot/jtreg/compiler/loopopts/superword/TestAliasingCheckPreLimitNotAvailable.java b/test/hotspot/jtreg/compiler/loopopts/superword/TestAliasingCheckPreLimitNotAvailable.java index e7009e87ae2..e86d6ec2314 100644 --- a/test/hotspot/jtreg/compiler/loopopts/superword/TestAliasingCheckPreLimitNotAvailable.java +++ b/test/hotspot/jtreg/compiler/loopopts/superword/TestAliasingCheckPreLimitNotAvailable.java @@ -27,7 +27,7 @@ * @summary Test where the pre_init was pinned before the pre-loop but after the * Auto_Vectorization_Check, and so it should not be used for the auto * vectorization aliasing check, to avoid a bad (circular) graph. - * @requires vm.gc == "ZGC" | vm.gc == "null" + * @requires vm.gc.Z * @run main/othervm * -XX:+IgnoreUnrecognizedVMOptions * -XX:CompileCommand=compileonly,*TestAliasingCheckPreLimitNotAvailable::test @@ -42,7 +42,7 @@ /* * @test id=all-flags-no-stress-seed * @bug 8371146 - * @requires vm.gc == "ZGC" | vm.gc == "null" + * @requires vm.gc.Z * @run main/othervm * -XX:+IgnoreUnrecognizedVMOptions * -XX:CompileCommand=compileonly,*TestAliasingCheckPreLimitNotAvailable::test
27-11-2025
TestAliasingCheckPreLimitNotAvailable_all-flags-fixed-stress-seed.jtr and TestAliasingCheckPreLimitNotAvailable_all-flags-no-stress-seed.jtr show failures on WIndows : [0.095s][error][gc] Failed to lookup symbol: VirtualAlloc2 Error occurred during initialization of VM ZGC requires Windows version 1803 or later AIX fails too : Error occurred during initialization of VM Option -XX:+UseZGC not supported
27-11-2025
Changeset: e3a08558 Branch: master Author: Emanuel Peter <epeter@openjdk.org> Date: 2025-11-26 14:58:50 +0000 URL: https://git.openjdk.org/jdk/commit/e3a085581bfa70437b73d4b0527a084e0c5c9aac
26-11-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/28449 Date: 2025-11-21 09:56:02 +0000
24-11-2025
Draft: https://github.com/openjdk/jdk/pull/28449
21-11-2025
[~rcastanedalo] I'll have a look at this now. Running with: ./java -XX:CompileCommand=compileonly,TestReduced::test -XX:CompileCommand=printcompilation,TestReduced::test -XX:CompileCommand=TraceAutoVectorization,TestReduced::test,SPECULATIVE_RUNTIME_CHECKS -XX:-TieredCompilation -Xcomp -XX:+StressLoopPeeling -XX:+UseZGC -XX:StressSeed=4 -XX:LoopUnrollLimit=48 -XX:PrintPhaseLevel=4 -XX:+TraceLoopOpts TestReduced.java I can see that indeed we are doing this: VTransform::apply_speculative_aliasing_runtime_checks: speculative aliasing analysis runtime checks The issue does seem to be dependent on -XX:+StressLoopPeeling, but with -XX:RepeatCompilation=100 it reproduces consistently. A simple workaround is to disable the speculative runtime checks: -XX:-UseAutoVectorizationSpeculativeAliasingChecks But that means that we simply do not vectorize cases that have aliasing. And it is not yet clear that the speculative runtime checks are the issue, though I suppose it is likely. I'll now investigate the root cause. Update 1: the "n" for which we find the bad graph comes from the speculative check: VPointer::make_speculative_aliasing_check_with: ... iff_speculate: 1849 If === 696 1894 [[ 1850 1851 ]] P=0.999999, C=-1.000000 87. AutoVectorization 3, after Adding Speculative Runtime Checks 2: 1668 CountedLoop 88. AutoVectorization 4, after Apply 2: 1668 CountedLoop PredicatesOff 89. Before Iter GVN 13 90. After Iter GVN 13 91. PhaseIdealLoop iterations 3 92. Before Beautify Loops 8 Bad graph detected in build_loop_late n: 1894 Bool === _ 1893 [[ 1849 ]] [ne] ... # Internal Error (.../src/hotspot/share/opto/loopnode.cpp:6860), pid=2211377, tid=2211409 # assert(false) failed: Bad graph detected in build_loop_late Update 2: img0_circular_grpah_at_assert.png Shows that the Bool node from the assert depends on a "1242 CastII". But that cast is set after the CFG that depends on the Bool node. We have a bad circle in the graph. A use before definition. Update 3: img1_circular_graph_after_check_inserted.png Shows that we already had a circular graph right after the check was inserted. Looking back at the logs, we find: VPointer::make_speculative_aliasing_check_with: pre_init: 1244 AddI === _ 1242 41 [[ 1515 1154 1852 ]] !orig=[1226] pre_limit: 1848 ConvL2I === _ 1847 [[ 1641 1853 ]] #int pre_lastL: 1859 MaxL === _ 1852 1858 [[ 1860 ]] main_init: 1861 ConvL2I === _ 1860 [[ 1868 ]] #int We can see that pre_init "1244 AddI" is on this circle, and seems to depend on a "1242 CastII" that is pinned under the "687 ParsePredicate ... #Auto_Vectorization_Check". That looks a bit suspicious. The pre_init would have to come from before the check, of course, and not after. In VPointer::make_speculative_aliasing_check_with, we do assert that the pre_init is VLoop::is_pre_loop_invariant. We find the ctrl of pre_init "1244 AddI", which happens to be "688 IfTrue" (they are connected via "1242 CastII", so that makes sense). We now check if "688 IfTrue" is VLoop::is_before_pre_loop. For that, we check if "688 IfTrue" dominates "1508 CountedLoop ... inner stride: 1 pre of N473". And that is the case: (rr) p pre_loop_head()->dump_bfs(100,find_node(688),"#c") dist dump --------------------------------------------- 9 688 IfTrue === 687 [[ 1089 1221 1115 1109 1102 1098 1096 1091 1242 ]] #1 !orig=[1118],400 !jvms: TestReduced::test @ bci:22 (line 16) 8 1221 If === 688 1220 [[ 1222 1225 ]] #Init Value Assertion Predicate P=0.999999, C=-1.000000 7 1225 IfTrue === 1221 [[ 1499 1199 ]] #1 !orig=[1192] 6 1199 RangeCheck === 1225 1198 [[ 1200 1203 ]] #Last Value Assertion Predicate P=0.999999, C=-1.000000 5 1203 IfTrue === 1199 [[ 1176 ]] #1 !orig=[1171] 4 1176 RangeCheck === 1203 1175 [[ 1177 1180 ]] #Init Value Assertion Predicate P=0.999999, C=-1.000000 3 1180 IfTrue === 1176 [[ 1158 ]] #1 !orig=[1150] 2 1158 RangeCheck === 1180 1157 [[ 1159 1162 ]] #Last Value Assertion Predicate P=0.999999, C=-1.000000 1 1162 IfTrue === 1158 [[ 1508 ]] #1 0 1508 CountedLoop === 1508 1162 1511 [[ 1484 1486 1491 1493 1497 1504 1507 1508 1509 1510 1514 1515 ]] inner stride: 1 pre of N473 !orig=[473],[444],[221] !jvms: TestReduced::test @ bci:25 (line 17) Hmm, it seems that we assume that "pre-loop invariance" is sufficient to be able to use values for the aliasing runtime check. But the aliasing runtime check happens before the pre loop. So if any of the used values are pinned between the aliasing check and the pre loop, that's a problem. The cases seems to be rare, but as the fuzzer example shows: the case is possible.
20-11-2025
[~rcastanedalo] agreed offline that I can take over this bug, since it is clearly SuperWord related.
20-11-2025
I could reproduce the failure all the way to JDK-8324751 using TestReduced.java and the following configuration: java -XX:CompileCommand=compileonly,TestReduced::test -XX:-TieredCompilation -Xcomp -XX:+StressLoopPeeling -XX:+UseZGC -XX:StressSeed=4 -XX:LoopUnrollLimit=48 -XX:PrintPhaseLevel=4 TestReduced.java. Before JDK-8324751, auto-vectorization does not kick in (see before-8324751.out attached), and the compilation succeeds. After JDK-8324751, auto-vectorization does transform the graph, adding speculative runtime checks etc. (judging from the output of -XX:PrintPhaseLevel=4, see after-8324751.out). After the auto-vectorization transformations and subsequent Idealization, the graph seems to be left in a bad state, and build_loop_late fails.
14-11-2025
The issue is independent of JDK-8342382. The newly attached reproducer (TestReduced.java) triggers the failure also using other GCs (ZGC). As suspected, JDK-8342382 only caused IdealLoopTree::policy_unroll to take the chain of decisions required to trigger the failure. Using ZGC and fiddling with LoopUnrollLimit triggers the same chain of decisions, leading to the same failure. See TestReduced.java for detailed instructions.
13-11-2025
Showed up again with the JavaFuzzer but I could not reproduce the issue: < Bad graph detected in build_loop_late < n: 13749 Bool === _ 13748 [[ 13710 ]] [ne] < early(n): 10270 CountedLoop === 10270 10129 10276 [[ 10268 10269 10270 10272 10273 10277 10278 ]] inner stride: 1 pre of N8574 multiversion_fast !orig=[8574],[8253],[3237],[3177],[1789] !jvms: Test_1788::mainTest @ bci:151 (line 133) < n->in(1): 13748 CmpI === _ 13747 299 [[ 13749 ]] < early(n->in(1)): 10270 CountedLoop === 10270 10129 10276 [[ 10268 10269 10270 10272 10273 10277 10278 ]] inner stride: 1 pre of N8574 multiversion_fast !orig=[8574],[8253],[3237],[3177],[1789] !jvms: Test_1788::mainTest @ bci:151 (line 133) < n->in(1)->in(1): 13747 OrI === _ 13769 13771 [[ 13748 ]] < early(n->in(1)->in(1)): 10270 CountedLoop === 10270 10129 10276 [[ 10268 10269 10270 10272 10273 10277 10278 ]] inner stride: 1 pre of N8574 multiversion_fast !orig=[8574],[8253],[3237],[3177],[1789] !jvms: Test_1788::mainTest @ bci:151 (line 133) < n->in(1)->in(2): 299 ConI === 0 [[ 1223 1224 1225 1226 1350 1349 3527 1269 1348 856 1347 1262 1273 1273 4352 1264 1264 7124 1250 1250 2892 1248 1248 1268 1249 857 2910 3276 3193 1346 3615 1272 1341 1340 1339 825 825 825 1246 1246 1246 7128 8542 8553 1271 845 845 1247 1247 884 1338 3211 3204 893 3693 1259 2963 1337 1332 1267 1266 1254 1247 846 846 3254 820 1262 1261 1261 1261 1254 1254 1331 1330 3298 3215 836 3802 8901 1329 866 2925 821 821 821 1251 1251 1248 9013 9599 13748 1260 1258 1253 9918 10152 1328 1323 3287 3226 1322 1321 900 1320 899 2991 1319 1314 1314 1313 1227 1313 1312 1271 1262 1249 1262 1274 1312 824 1312 1311 1255 1255 1255 1259 404 1311 1311 1310 1310 896 403 896 1309 1309 895 895 2976 807 1308 1308 806 1307 1256 809 1257 3200 3189 1306 1305 1304 3265 824 1256 1270 1273 1272 1248 1251 887 8575 887 8571 133 10163 1258 3119 1270 1228 1228 4900 1229 1229 3222 1230 1230 13771 1275 1275 1231 1231 1260 1260 877 877 10162 9012 1257 1232 1232 1232 3007 13769 4700 1301 1301 1300 2818 816 816 816 1300 1233 1233 1233 1299 1299 817 817 817 1299 1298 1298 1298 1297 1297 872 872 1296 1296 1234 1234 1234 871 871 2941 1295 1295 1294 1293 1235 1235 1235 1235 1292 1291 1288 1288 1236 1236 1236 1236 1287 1287 1286 1286 1237 1237 1237 1286 1285 1238 1238 1238 1285 1285 1284 1284 868 868 1283 1283 867 867 2926 1282 1282 1281 1280 1279 1239 1278 1258 1240 3243 1250 2848 824 1241 1241 1263 1242 1242 1263 1243 1243 1249 1249 1274 1244 1244 1274 8564 4566 1276 10272 8538 1261 1245 1245 1245 1252 1259 4444 8549 8560 1276 2833 820 820 ]] #int:0 < early(n->in(1)->in(2)): 0 Root === 0 105 4732 104 103 102 132 4682 77 4673 101 100 129 99 98 97 96 4664 131 76 124 11476 125 4652 130 106 108 88 4881 87 8441 12647 4851 4872 35 36 37 38 39 40 41 42 10632 118 4963 46 47 48 49 50 51 52 53 54 55 56 57 58 59 4762 116 115 75 126 128 127 67 68 11488 114 79 78 4863 [[ 0 1 370 287 291 304 1009 1974 2241 2250 299 2471 993 1608 2443 2226 1973 2217 1664 2719 911 2210 2201 1571 1980 2641 2998 2194 1979 305 1983 306 307 347 1008 1012 1015 1018 1021 5868 3155 1024 1707 1708 308 2185 313 1695 318 2177 5865 2174 2171 5864 948 2015 1497 1685 2157 1988 2158 2640 2689 2767 2795 2671 1067 1068 2699 1832 5863 2149 3170 3162 1838 3139 3146 3033 1088 2146 3163 3050 2143 2783 2246 1491 3149 1537 2023 2461 1000 2024 1498 2709 1790 1794 3074 1642 2129 2460 2263 2130 945 2121 1992 2118 2115 1628 2101 1991 2102 1524 2096 2093 1525 2016 1520 2090 2001 1590 2002 2076 3054 1527 2077 1517 1579 5837 2007 3127 2071 2010 2068 2065 2013 1548 2051 2052 2043 2040 2037 5771 3326 5764 5649 3719 5119 5118 5092 5100 6571 6572 6573 6578 6580 7027 7029 7037 7051 7064 7075 7089 7090 7091 7095 7096 7520 7526 7530 7536 7718 8037 8042 8045 8046 8048 8068 8070 8072 8362 8444 8483 8484 8516 8517 10677 10749 10763 10793 10821 11557 11570 12728 13518 13539 13540 13548 13695 ]] < < LCA(n): 7429 IfTrue === 7428 [[ 13710 8245 13732 ]] #1 < n->out(0): 13710 If === 7429 13749 [[ 13711 13712 ]] P=0.999000, C=-1.000000 < n->out(0)->out(0): 13711 IfTrue === 13710 [[ 10128 ]] #1 < n->out(0)->out(1): 13712 IfFalse === 13710 [[ 13714 ]] #0 < < idoms of early "10270 CountedLoop": < idom[4]: 7429 IfTrue < idom[3]: 13710 If < idom[2]: 13711 IfTrue < idom[1]: 10128 If < idom[0]: 10129 IfTrue < n: 10270 CountedLoop < < idoms of (wrong) LCA "7429 IfTrue": < n: 7429 IfTrue < < Real LCA of early "10270 CountedLoop" (idom[4]) and wrong LCA "7429 IfTrue": < 7429 IfTrue === 7428 [[ 13710 8245 13732 ]] #1 < < # < # A fatal error has been detected by the Java Runtime Environment: < # < # Internal Error (/workspace/open/src/hotspot/share/opto/loopnode.cpp:6860), pid=34099, tid=25859 < # assert(false) failed: Bad graph detected in build_loop_late
11-11-2025
Looks like a regression in JDK 26 b17, narrowing it down... It somehow points to JDK-8342382. Not sure how that one could trigger this. Roberto said "JDK-8342382 made the G1 post-barrier more lightweight, which affects C2's loop unrolling heuristic: C2 unrolls more now than before in the presence of G1 writes. That is the only interaction I can think about."
07-11-2025
ILW = Bad graph, single fuzzer case, disable compilation of affected method = HML = P3
05-11-2025