JDK-8294540 : Remove Opaque2Node: it is broken and triggers assert
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,17,20
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: x86_64
  • Submitted: 2022-09-28
  • Updated: 2022-12-14
  • Resolved: 2022-12-05
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 20
20 b27Fixed
Related Reports
Duplicate :  
JDK-8293993 - C2: Check removal of Opaque2 nodes
Relates :  
JDK-8269820 - C2 PhaseIdealLoop::do_unroll get wrong opaque node
Relates :  
JDK-8292088 - C2: assert(is_OuterStripMinedLoop()) failed: invalid node class: IfTrue
Relates :  
JDK-8298176 - remove OpaqueZeroTripGuardPostLoop once main-loop disappears
Relates :  
JDK-8298089 - Rename Opaque nodes to something more useful
Relates :  
JDK-8298019 - Investigate: reduce register pressure by avoiding use of pre-incremented Phi after loop
Description
Test: compiler/loopopts/superword/SumRed_Long.java

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (c:\sb\prod\1664381000\workspace\open\src\hotspot\share\opto\loopTransform.cpp:2226), pid=34748, tid=3064
#  Error: assert(opaq->outcnt() == 1 && opaq->in(1) == limit) failed
#
# JRE version: Java(TM) SE Runtime Environment (20.0+17) (fastdebug build 20-ea+17-1191)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 20-ea+17-1191, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Core dump will be written. Default location: C:\sb\prod\1664393007\testoutput\test-support\jtreg_open_test_hotspot_jtreg_tier1_compiler_3\scratch\3\hs_err_pid34748.mdmp
#

---------------  T H R E A D  ---------------

Current thread (0x000002336782fb00):  JavaThread "C2 CompilerThread1" daemon [_thread_in_native, id=3064, stack(0x0000007ecd900000,0x0000007ecda00000)]


Current CompileTask:
C2:   1080  274             java.net.URI$1::create (10 bytes)

Stack: [0x0000007ecd900000,0x0000007ecda00000]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0xc04b11]  os::win32::platform_print_native_stack+0xf1  (os_windows_x86.cpp:236)
V  [jvm.dll+0xe687ee]  VMError::report+0x10be  (vmError.cpp:841)
V  [jvm.dll+0xe6a2fe]  VMError::report_and_die+0x65e  (vmError.cpp:1700)
V  [jvm.dll+0xe6aa84]  VMError::report_and_die+0x64  (vmError.cpp:1481)
V  [jvm.dll+0x57aa67]  report_vm_error+0xb7  (debug.cpp:285)
V  [jvm.dll+0xa7d58d]  PhaseIdealLoop::do_unroll+0x4bd  (loopTransform.cpp:2226)
V  [jvm.dll+0xa847a1]  IdealLoopTree::iteration_split_impl+0x7c1  (loopTransform.cpp:3905)
V  [jvm.dll+0xa83ea0]  IdealLoopTree::iteration_split+0x160  (loopTransform.cpp:3929)
V  [jvm.dll+0xa83d6f]  IdealLoopTree::iteration_split+0x2f  (loopTransform.cpp:3913)
V  [jvm.dll+0xa83fc0]  IdealLoopTree::iteration_split+0x280  (loopTransform.cpp:3945)
V  [jvm.dll+0xa83fc0]  IdealLoopTree::iteration_split+0x280  (loopTransform.cpp:3945)
V  [jvm.dll+0xa83fc0]  IdealLoopTree::iteration_split+0x280  (loopTransform.cpp:3945)
V  [jvm.dll+0xa83fc0]  IdealLoopTree::iteration_split+0x280  (loopTransform.cpp:3945)
V  [jvm.dll+0xa83fc0]  IdealLoopTree::iteration_split+0x280  (loopTransform.cpp:3945)
V  [jvm.dll+0xa83fc0]  IdealLoopTree::iteration_split+0x280  (loopTransform.cpp:3945)
V  [jvm.dll+0xa92271]  PhaseIdealLoop::build_and_optimize+0x1131  (loopnode.cpp:4530)
V  [jvm.dll+0x51037b]  Compile::Optimize+0x109b  (compile.cpp:2414)
V  [jvm.dll+0x50d1ed]  Compile::Compile+0x14ad  (compile.cpp:831)
V  [jvm.dll+0x433715]  C2Compiler::compile_method+0x145  (c2compiler.cpp:116)
V  [jvm.dll+0x527047]  CompileBroker::invoke_compiler_on_method+0x8a7  (compileBroker.cpp:2243)
V  [jvm.dll+0x5247dd]  CompileBroker::compiler_thread_loop+0x23d  (compileBroker.cpp:1917)
V  [jvm.dll+0x7efa82]  JavaThread::thread_main_inner+0x282  (javaThread.cpp:700)
V  [jvm.dll+0xde1ec7]  Thread::call_run+0x257  (thread.cpp:229)
V  [jvm.dll+0xc03468]  thread_native_entry+0xb8  (os_windows.cpp:547)
C  [ucrtbase.dll+0x1fb80]
C  [KERNEL32.DLL+0x84d4]
C  [ntdll.dll+0x51791]
Comments
Changeset: 619b68c5 Author: Emanuel Peter <epeter@openjdk.org> Date: 2022-12-05 08:30:31 +0000 URL: https://git.openjdk.org/jdk/commit/619b68c5d1908de335cefd536963cadd57472925
05-12-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/11477 Date: 2022-12-02 09:58:22 +0000
02-12-2022
Will remove Opaque2 node, as it seems broken anyway
29-11-2022
Attached GraphAtAssert.png shows the 5942 Opaque1 and the 6348 CastII. Both CmpI compare against the same limit but the problem is that PhaseIdealLoop::reorg_offsets added nodes in-between that confuse the verification code. A straightforward fix would be to disable PhaseIdealLoop::reorg_offsets which is useless anyway in its current form (see [~chagedorn]'s nice analysis in https://github.com/openjdk/jdk/pull/10306).
17-11-2022
While this is similar to JDK-8269820, the root cause seems to be different (I verified this by applying the prototype fix that Roland proposed in https://github.com/openjdk/jdk17/pull/208#issuecomment-878257990).
14-11-2022
Here's the crashing thread stack for the jdk-20+20-1380-tier3 sighting: compiler/loopopts/superword/RedTest_int.java --------------- T H R E A D --------------- Current thread (0x000001de6569eda0): JavaThread "C2 CompilerThread2" daemon [_thread_in_native, id=54920, stack(0x0000005c04300000,0x0000005c04400000)] Current CompileTask: C2: 1351 304 java.net.URI$Parser::parse (243 bytes) Stack: [0x0000005c04300000,0x0000005c04400000] Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0xc0b6d1] os::win32::platform_print_native_stack+0xf1 (os_windows_x86.cpp:236) V [jvm.dll+0xe6e21e] VMError::report+0x10be (vmError.cpp:841) V [jvm.dll+0xe6fd14] VMError::report_and_die+0x644 (vmError.cpp:1700) V [jvm.dll+0xe70454] VMError::report_and_die+0x64 (vmError.cpp:1481) V [jvm.dll+0x57fb77] report_vm_error+0xb7 (debug.cpp:285) V [jvm.dll+0xa8486d] PhaseIdealLoop::do_unroll+0x4bd (loopTransform.cpp:2228) V [jvm.dll+0xa8ba81] IdealLoopTree::iteration_split_impl+0x7c1 (loopTransform.cpp:3907) V [jvm.dll+0xa8b180] IdealLoopTree::iteration_split+0x160 (loopTransform.cpp:3931) V [jvm.dll+0xa8b04f] IdealLoopTree::iteration_split+0x2f (loopTransform.cpp:3915) V [jvm.dll+0xa8b2a0] IdealLoopTree::iteration_split+0x280 (loopTransform.cpp:3947) V [jvm.dll+0xa8b2a0] IdealLoopTree::iteration_split+0x280 (loopTransform.cpp:3947) V [jvm.dll+0xa8b2a0] IdealLoopTree::iteration_split+0x280 (loopTransform.cpp:3947) V [jvm.dll+0xa8b2a0] IdealLoopTree::iteration_split+0x280 (loopTransform.cpp:3947) V [jvm.dll+0xa8b2a0] IdealLoopTree::iteration_split+0x280 (loopTransform.cpp:3947) V [jvm.dll+0xa8b2a0] IdealLoopTree::iteration_split+0x280 (loopTransform.cpp:3947) V [jvm.dll+0xa995c1] PhaseIdealLoop::build_and_optimize+0x1131 (loopnode.cpp:4519) V [jvm.dll+0x51534b] Compile::Optimize+0x109b (compile.cpp:2415) V [jvm.dll+0x5121cd] Compile::Compile+0x148d (compile.cpp:832) V [jvm.dll+0x438a65] C2Compiler::compile_method+0x145 (c2compiler.cpp:116) V [jvm.dll+0x52bf84] CompileBroker::invoke_compiler_on_method+0x884 (compileBroker.cpp:2243) V [jvm.dll+0x52977d] CompileBroker::compiler_thread_loop+0x23d (compileBroker.cpp:1917) V [jvm.dll+0x7f5f92] JavaThread::thread_main_inner+0x282 (javaThread.cpp:700) V [jvm.dll+0xde8e27] Thread::call_run+0x257 (thread.cpp:229) V [jvm.dll+0xc09fe8] thread_native_entry+0xb8 (os_windows.cpp:547) C [ucrtbase.dll+0x2268a] C [KERNEL32.DLL+0x17974] C [ntdll.dll+0x5a0b1]
13-10-2022
I can reproduce it on my ubuntu linux too, not just windows, changed OS to "generic". Will look into this. opaq->in(1) == limit does not hold, we have two different CastII nodes. (rr) p opaq->in(1)->dump_bfs(100,limit,"#+-") dist dump --------------------------------------------- 0 6332 CastII === _ 6331 [[ 5917 ]] #int:1..max-2:www !jvms: String::<init> @ bci:3 (line 1487) StringBuilder::toString @ bci:5 (line 453) URI::validSchemeAndPath @ bci:24 (line 867) URI::<init> @ bci:17 (line 860) URI$1::create @ bci:6 (line 3647) 1 6331 AddI === _ 6330 1418 [[ 6332 ]] !jvms: String::<init> @ bci:3 (line 1487) StringBuilder::toString @ bci:5 (line 453) URI::validSchemeAndPath @ bci:24 (line 867) URI::<init> @ bci:17 (line 860) URI$1::create @ bci:6 (line 3647) 2 1418 ConI === 0 [[ 1501 952 1517 515 387 390 2698 487 486 485 484 6083 444 2654 478 477 476 2687 472 5505 1497 396 466 465 464 463 461 389 1461 404 403 495 439 451 449 497 526 2139 1318 397 5482 440 5477 2676 435 434 433 432 5489 494 5927 492 426 425 424 419 418 417 416 5646 1323 388 491 6185 6188 6201 6325 6328 6331 6334 6337 ]] #int:-1 !jvms: URI$Parser::at @ bci:2 (line 2970) URI$Parser::parse @ bci:33 (line 3148) URI::<init> @ bci:19 (line 620) URI::validSchemeAndPath @ bci:27 (line 867) URI::<init> @ bci:17 (line 860) URI$1::create @ bci:6 (line 3647) 3 6328 AddI === _ 6327 1418 [[ 6329 ]] !jvms: String::<init> @ bci:3 (line 1487) StringBuilder::toString @ bci:5 (line 453) URI::validSchemeAndPath @ bci:24 (line 867) URI::<init> @ bci:17 (line 860) URI$1::create @ bci:6 (line 3647) 4 6329 CastII === _ 6328 [[ 2690 ]] #int:1..max-2:www !jvms: StringBuilder::toString @ bci:5 (line 453) URI::validSchemeAndPath @ bci:24 (line 867) URI::<init> @ bci:17 (line 860) URI$1::create @ bci:6 (line 3647)
04-10-2022
Looks like it was "pre-existing" bug which was exposed by changes in java.net.URI class: JDK-8272702: Resolving URI relative path with no / may lead to incorrect toString https://github.com/openjdk/jdk/commit/79597f1ea6844f374beeeba219719cd9d5fe7d03 Compilation replay passed after I revert the change.
30-09-2022
You are right, Dean. My local copy of replay file was wrong. After updating I reproduced failure with next flags: java -Xbatch -XX:+ReplayCompiles -XX:ReplayDataFile=replay_pid34748.log -XX:+ReplayIgnoreInitErrors -XX:+PrintCompilation -XX:+IgnoreUnrecognizedVMOptions -XX:LoopUnrollLimit=250 -XX:CompileThresholdScaling=0.1 -XX:-SuperWordReductions -XX:LoopMaxUnroll=8 -XX:-TieredCompilation -ea -esa
30-09-2022
[~kvn], I'm not seeing the error. What is the length of line 999 in your replay file? It should be 6796. "position 4096" seems strange.
30-09-2022
I was not able to reproduce the failure because of method's class: 96 3 b 4 java.net.URI$1::create (10 bytes) Error while parsing line 999 at position 4096: Can't find holder klass
30-09-2022
ILW = assert in debug build; intermittent; disable compilation of affected method = MMM = P3
28-09-2022
I attached replay file. We had few loop optimization changes pushed in past week.
28-09-2022