JDK-8312631 : C2 crash: assert(false) failed: Unexpected use of reducible Phi
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 22
  • Priority: P2
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2023-07-25
  • Updated: 2023-12-06
  • Resolved: 2023-12-06
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 22
22Resolved
Related Reports
Relates :  
JDK-8287061 - Support for rematerializing scalar replaced objects participating in allocation merges
Sub Tasks
JDK-8319256 :  
Print more diagnostic information when an unexpected user is found in a Phi - Resolved
Description
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S39671/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/bf8029e5-1d76-4ae0-ab70-8de53ef552b3/runs/d76b3c83-cc10-4598-9729-21453837832d/workspace/open/src/hotspot/share/opto/escape.cpp:723), pid=3950839, tid=3969104
#  assert(false) failed: Unexpected use of reducible Phi.
#
# JRE version: Java(TM) SE Runtime Environment (22.0+8) (fastdebug build 22-ea+8-530)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-ea+8-530, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xbab5ab]  ConnectionGraph::reduce_phi(PhiNode*)+0x2eb

---------------  S U M M A R Y ------------

Command Line: -Xbootclasspath/a:/opt/mach5/mesos/work_dir/slaves/cd627e65-f015-4fb1-a1d2-b6c9b8127f98-S73195/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/f1d9bb01-eeeb-49b0-81e5-d47dacdef86e/runs/b62aa02e-2311-488a-94f4-2d770dfee85a/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_runthese_RunThese30M_java/scratch/0/wb.jar -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -Djava.security.manager=allow -XX:MaxRAMPercentage=4.16667 -Dtest.boot.jdk=/opt/mach5/mesos/work_dir/jib-master/install/jdk/20/36/bundles/linux-x64/jdk-20_linux-x64_bin.tar.gz/jdk-20 -Djava.io.tmpdir=/opt/mach5/mesos/work_dir/slaves/cd627e65-f015-4fb1-a1d2-b6c9b8127f98-S73195/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/f1d9bb01-eeeb-49b0-81e5-d47dacdef86e/runs/b62aa02e-2311-488a-94f4-2d770dfee85a/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_runthese_RunThese30M_java/tmp -XX:MaxRAMPercentage=50 -Djava.net.preferIPv6Addresses=false -XX:+DisplayVMOutputToStderr -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags -XX:+DisableExplicitGC -XX:+StartAttachListener -Xlog:monitorinflation=info:file=../monitorinflation.log::filesize=500m -Djava.io.tmpdir=/opt/mach5/mesos/work_dir/slaves/cd627e65-f015-4fb1-a1d2-b6c9b8127f98-S73195/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/f1d9bb01-eeeb-49b0-81e5-d47dacdef86e/runs/b62aa02e-2311-488a-94f4-2d770dfee85a/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_runthese_RunThese30M_java/scratch/0/java.io.tmpdir -Duser.home=/opt/mach5/mesos/work_dir/slaves/cd627e65-f015-4fb1-a1d2-b6c9b8127f98-S73195/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/f1d9bb01-eeeb-49b0-81e5-d47dacdef86e/runs/b62aa02e-2311-488a-94f4-2d770dfee85a/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_runthese_RunThese30M_java/scratch/0/user.home -agentpath:/opt/mach5/mesos/work_dir/jib-master/install/jdk-22+8-530/linux-x64-debug.test/hotspot/jtreg/native/libJvmtiStressModule.so -XX:NativeMemoryTracking=detail -Djdk.test.lib.random.seed=-8705325704436501488 applications.kitchensink.process.stress.Main /opt/mach5/mesos/work_dir/slaves/cd627e65-f015-4fb1-a1d2-b6c9b8127f98-S73195/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/f1d9bb01-eeeb-49b0-81e5-d47dacdef86e/runs/b62aa02e-2311-488a-94f4-2d770dfee85a/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_runthese_RunThese30M_java/scratch/0/kitchensink.final.properties

Host: Intel(R) Xeon(R) Platinum 8358 CPU @ 2.60GHz, 12 cores, 23G, Oracle Linux Server release 8.7
Time: Tue Jul 25 03:27:37 2023 UTC elapsed time: 1927.081992 seconds (0d 0h 32m 7s)

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

Current thread (0x00007f27563ee8c0):  JavaThread "C2 CompilerThread1" daemon [_thread_in_native, id=3969104, stack(0x00007f2686fe9000,0x00007f26870e9000) (1024K)]


Current CompileTask:
C2:1927082 43351       4       com.oracle.tck.lib.autd2.processors.tc.TGFTestCaseMethodSetting::process (21 bytes)

Stack: [0x00007f2686fe9000,0x00007f26870e9000],  sp=0x00007f26870e3dc0,  free space=1003k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xbab5ab]  ConnectionGraph::reduce_phi(PhiNode*)+0x2eb  (escape.cpp:723)
V  [libjvm.so+0xbc38ee]  ConnectionGraph::compute_escape()+0x24fe  (escape.cpp:406)
V  [libjvm.so+0xbc4023]  ConnectionGraph::do_analysis(Compile*, PhaseIterGVN*)+0x133  (escape.cpp:116)
V  [libjvm.so+0x9ead8e]  Compile::Optimize()+0x87e  (compile.cpp:2308)
V  [libjvm.so+0x9ed5a0]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1b60  (compile.cpp:850)
V  [libjvm.so+0x8490ab]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x12b  (c2compiler.cpp:119)
V  [libjvm.so+0x9f9490]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xa00  (compileBroker.cpp:2265)
V  [libjvm.so+0x9fa318]  CompileBroker::compiler_thread_loop()+0x618  (compileBroker.cpp:1944)
V  [libjvm.so+0xeb451c]  JavaThread::thread_main_inner()+0xcc  (javaThread.cpp:720)
V  [libjvm.so+0x179494a]  Thread::call_run()+0xba  (thread.cpp:217)
V  [libjvm.so+0x1495431]  thread_native_entry(Thread*)+0x121  (os_linux.cpp:783)
Comments
I'll try to reproduce this on my side again. Thanks for all the help [~thartmann].
06-12-2023
I'm closing this as "Not an Issue" for now, assuming that JDK-8319256 fixed the underlying issue. Please re-open if this shows up again.
06-12-2023
The problem is that we were never able to reliable reproduce this. I just showed up in our testing every few days.
05-12-2023
We can undo that part in local report and submit testing to see if it indeed fixed the issue.
05-12-2023
I made the change to the computation of 'j' because I suspected the previous logic may be causing some AddPNode to be skipped (causing the issue in this work item). In hindsight, I should probably have left that change for another PR...
04-12-2023
Still no luck. [~cslucas], are we sure that JDK-8319256 did not introduce any change in behavior? Looking at it again, the computation of 'j' changed: https://github.com/openjdk/jdk/commit/9cce9fe06780aa095b3aabdfa421f376ca7bfd08#diff-03f7ae3cf79ff61be6e4f0590b7809a87825b073341fdbfcf36143b99c304474L596
04-12-2023
Thank you for the update, [~thartmann].
28-11-2023
[~cslucas] I checked every couple of days but unfortunately it didn't reproduce since you pushed that change.
28-11-2023
[~thartmann] did you see this error happening after I added more diagnostic/verification (https://github.com/openjdk/jdk/pull/16465) ? Thank you for helping with this!
27-11-2023
Sighting in loom repo too, same assert but slightly different call back. V [libjvm.dylib+0x112f43c] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x564 (escape.cpp:3905) V [libjvm.dylib+0x112fc64] VMError::report_and_die(Thread*, char const*, int, unsigned long, VMErrorType, char const*, char*)+0x0 V [libjvm.dylib+0x56de24] print_error_for_unit_test(char const*, char const*, char*)+0x0 V [libjvm.dylib+0x640b70] ConnectionGraph::split_unique_types(GrowableArray<Node*>&, GrowableArray<ArrayCopyNode*>&, GrowableArray<MergeMemNode*>&, Unique_Node_List&)+0x3098 V [libjvm.dylib+0x639ce0] ConnectionGraph::compute_escape()+0x1600 V [libjvm.dylib+0x6385a4] ConnectionGraph::do_analysis(Compile*, PhaseIterGVN*)+0xd8 V [libjvm.dylib+0x4d0f50] Compile::Optimize()+0x4a0 V [libjvm.dylib+0x4cf514] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x11d4 V [libjvm.dylib+0x3932a4] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1e0 V [libjvm.dylib+0x4ecbec] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x854 V [libjvm.dylib+0x4ec030] CompileBroker::compiler_thread_loop()+0x348 V [libjvm.dylib+0x8c0664] JavaThread::thread_main_inner()+0x1dc V [libjvm.dylib+0x1072e6c] Thread::call_run()+0xf4 V [libjvm.dylib+0xe37ad8] thread_native_entry(Thread*)+0x138 C [libsystem_pthread.dylib+0x706c] _pthread_start+0x94
08-11-2023
Sounds good, thank you!
02-11-2023
Hey [~thartmann], sorry for the delay getting back to you. I thought you were not seeing this issue anymore. I wasn't able to reproduce it on my side. I'll follow your suggestion and create a PR to print more diagnostic information when the error happens and hopefully, that will help me understand the root cause of this.
01-11-2023
[~cslucas] Any update on this? This still triggers regularly in our CI.
01-11-2023
Unfortunately, it has happened only once and we don't have any reproducer or replay file. The fix looks harmless, so, it might be better to have it than risking an error in production.
21-09-2023
Ideally we would have a reproducer for mainline. Do you have a replay file or can you reproduce it in your CI?
20-09-2023
Thanks for the pointer! Are you planning to bring that one into mainline? Should I file a new bug?
20-09-2023
[~mdoerr] that looks like JDK-8262831 which we reproduced and fixed in Valhalla but assumed mainline would not be affected. Maybe, after JDK-8287061, mainline is affected as well.
20-09-2023
We have seen "assert(base->is_AddP()) failed: should be addp but is Phi" (memnode.cpp:3891) while running "tools/javac/patterns/PatternDesugaring" (only once). Could this be the same issue?
19-09-2023
Sorry for the delay, I was out for a few days. Since the issue is quite intermittent, I'm not able to reproduce it manually but it just occurs every few days in our testing. [~cslucas] would it make sense to integrate (parts of) your debugging code with a separate PR and then wait for the issue to trigger again in our testing?
01-09-2023
Gentle ping.
31-08-2023
Tobias, so far I haven't been able to reproduce this. I've been running some test groups of TCK21 in a loop for a few days so far. Would you be able to execute your tests with a patched JVM to print more debugging information? https://github.com/JohnTortugo/jdk/commit/825a711b1b2c5efddd7f871035ecafcc9cb190a5 I believe this might just be a matter of the remaining AddP node being dead (outcnt() == 0) but the current check doesn't take that into consideration.
25-08-2023
Thank you Tobias. I was kind of suspecting that JVMTI might be involved in the problem but it's just a hunch.
15-08-2023
One additional data point. In the failing cases, JVMTI seems to be enabled: JvmtiExport can_access_local_variables 1 JvmtiExport can_hotswap_or_post_breakpoint 1 JvmtiExport can_post_on_exceptions 1 And especially C->env()->should_retain_local_variables() affects EA.
15-08-2023
The TCK tests are executed as part of a larger stress test that runs for several hours. It often triggers a specific deoptimization->re-profiling->re-compilation sequence that is required to reproduce the issue. As far as I can tell, it was not always the same test but the same methods that failed. It only happened 6 times.
15-08-2023
Thank you Tobias for the logs. The new assert helped drill down a little on where the root of the problem is, unfortunately, I'm still not able to reproduce the problem on my end. Can you tell me what's the name of the TCK test that is failing? Was it always the same test that failed?
14-08-2023
With release builds, we are also observing intermittent crashes in the same C2 compiled method(s). # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f884356809f, pid=4353, tid=15870 # # JRE version: Java(TM) SE Runtime Environment (22.0) (build 22-internal-2023-07-27-0302354.leonid.mesnik.ks-apps) # Java VM: Java HotSpot(TM) 64-Bit Server VM (22-internal-2023-07-27-0302354.leonid.mesnik.ks-apps, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, parallel gc, linux-amd64) # Problematic frame: # J 47374663 c2 com.oracle.tck.lib.autd2.processors.tc.TGFTestCaseMethodSetting.process(Lcom/oracle/tck/lib/autd2/LifePhase;Lcom/oracle/tck/lib/autd2/Context;)V (13 bytes) @ 0x00007f884356809f [0x00007f8843565e40+0x000000000000225f] Stack: [0x00007f8635b5d000,0x00007f8635c5d000], sp=0x00007f8635c598b0, free space=1010k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) J 47374663 c2 com.oracle.tck.lib.autd2.processors.tc.TGFTestCaseMethodSetting.process(Lcom/oracle/tck/lib/autd2/LifePhase;Lcom/oracle/tck/lib/autd2/Context;)V (13 bytes) @ 0x00007f884356809f [0x00007f8843565e40+0x000000000000225f] J 47366120 c2 com.oracle.tck.lib.autd2.AUTD2Utils.iterateThroughProcessorsUntilAllAreDone(Lcom/oracle/tck/lib/autd2/Context;Ljava/util/TreeMap;Lcom/oracle/tck/lib/autd2/LifePhase;Ljava/util/List;)V (207 bytes) @ 0x00007f8841cdaacc [0x00007f8841cda2c0+0x000000000000080c] J 47368662 c1 com.oracle.tck.lib.autd2.AUTD2Utils.iterateLifePhases(Lcom/oracle/tck/lib/autd2/Context;[Lcom/oracle/tck/lib/autd2/LifePhase;)V (173 bytes) @ 0x00007f8838c3b774 [0x00007f8838c3aa60+0x0000000000000d14] J 47368031 c1 com.oracle.tck.lib.autd2.AUTD2Utils.iterateTestCaseLifePhase(Lcom/oracle/tck/lib/autd2/TestCaseContext;)Lcom/oracle/tck/lib/autd2/TestResult; (37 bytes) @ 0x00007f88390f1aac [0x00007f88390f1980+0x000000000000012c] J 47368067 c1 com.oracle.tck.lib.autd2.processors.tg.RunningTestCases.lambda$process$0(Lcom/oracle/tck/lib/autd2/TestGroupContext;Lcom/oracle/tck/lib/autd2/TestCaseContext;)V (114 bytes) @ 0x00007f88390d15fc [0x00007f88390d1380+0x000000000000027c] J 47368002 c1 com.oracle.tck.lib.autd2.processors.tg.RunningTestCases$$Lambda+0x00007f87ecc0cd30.accept(Ljava/lang/Object;)V (16 bytes) @ 0x00007f883a16ef7c [0x00007f883a16eec0+0x00000000000000bc] # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f6f2d5113d8, pid=1533187, tid=3780315 # # JRE version: Java(TM) SE Runtime Environment (22.0+8) (build 22-ea+8-534) # Java VM: Java HotSpot(TM) 64-Bit Server VM (22-ea+8-534, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, parallel gc, linux-amd64) # Problematic frame: # J 14492541 c2 com.sun.tck.lib.tgf.TGFUtils.getDeclaredMember(Ljava/lang/Class;Ljava/lang/String;Lcom/sun/tck/lib/tgf/TGFUtils$MemberProcessor;)Ljava/lang/reflect/Member; (203 bytes) @ 0x00007f6f2d5113d8 [0x00007f6f2d510a80+0x0000000000000958] Stack: [0x00007f6d1e2a4000,0x00007f6d1e3a4000], sp=0x00007f6d1e3a0a30, free space=1010k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) J 14492541 c2 com.sun.tck.lib.tgf.TGFUtils.getDeclaredMember(Ljava/lang/Class;Ljava/lang/String;Lcom/sun/tck/lib/tgf/TGFUtils$MemberProcessor;)Ljava/lang/reflect/Member; (203 bytes) @ 0x00007f6f2d5113d8 [0x00007f6f2d510a80+0x0000000000000958] J 14492780 c1 com.sun.tck.lib.tgf.TGFUtils.getRawDataFromTextReference(Ljava/lang/Object;Ljava/lang/Class;Ljava/io/PrintWriter;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/Object; (269 bytes) @ 0x00007f6f27186574 [0x00007f6f271864a0+0x00000000000000d4] J 14492878 c1 com.sun.tck.lib.tgf.TestDataCollector.checkIfTestCaseShouldBeExecuted(Ljava/lang/reflect/Method;Ljava/lang/Object;Ljava/lang/Class;Ljava/io/PrintWriter;)V (199 bytes) @ 0x00007f6f26bc27fc [0x00007f6f26bc19a0+0x0000000000000e5c] J 14492877 c1 com.oracle.tck.lib.autd2.processors.tg.RunningTestCases.lambda$process$0(Lcom/oracle/tck/lib/autd2/TestGroupContext;Lcom/oracle/tck/lib/autd2/TestCaseContext;)V (114 bytes) @ 0x00007f6f26f152f4 [0x00007f6f26f150a0+0x0000000000000254] J 14492876 c1 com.oracle.tck.lib.autd2.processors.tg.RunningTestCases$$Lambda+0x00007f6ece530660.accept(Ljava/lang/Object;)V (16 bytes) @ 0x00007f6f27015c54 [0x00007f6f27015ac0+0x0000000000000194] J 23907 c2 java.lang.Iterable.forEach(Ljava/util/function/Consumer;)V java.base@22-ea (39 bytes) @ 0x00007f6f2cb6ce08 [0x00007f6f2cb6cd40+0x00000000000000c8]
11-08-2023
This happened again, this time with the new debug code. Unfortunately, there was an output overflow (see attached log1.txt). # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/workspace/open/src/hotspot/share/opto/escape.cpp:3904), pid=1589262, tid=1607813 # assert(false) failed: Unexpected user of reducible Phi -> AddP # # JRE version: Java(TM) SE Runtime Environment (22.0) (fastdebug build 22-internal-2023-08-10-0638087.tobias.hartmann.jdk2) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-internal-2023-08-10-0638087.tobias.hartmann.jdk2, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0xbbd18d] ConnectionGraph::split_unique_types(GrowableArray<Node*>&, GrowableArray<ArrayCopyNode*>&, GrowableArray<MergeMemNode*>&, Unique_Node_List&)+0x2d7d I was not able to reproduce the issue with Replay Compilation.
11-08-2023
Thanks for looking into this, [~cslucas]. Unfortunately, we are not able to share the internal test and it also does not seem to reproduce (yet). I attached the replay file and hs_err files. We could add more debugging output to the assert to get some additional hints once this reproduces again. > Any chance that EliminateAllocation was off in these tests? No, the VM was not executed with any relevant flags (see hs_err file).
26-07-2023
[~cslucas] It was [~thartmann] that assigned this to you. :) EliminateAllocations was not off. Unfortunately the test cannot be shared.
26-07-2023
Any chance that EliminateAllocation was off in these tests?
25-07-2023
Thanks for assigning this to me @david.holmes. I'm already taking a look into it. Can you give me more information about which JCK class/test failed or perhaps share the internal stress test :-)?
25-07-2023
ILW = Assert during Escape Analysis (regression in JDK 22 b07 from JDK-8287061), intermittent with stress tests + JCK, -XX:-ReduceAllocationMerges = HML = P2
25-07-2023
Code was added by JDK-8287061. The failure happened only once with an internal stress test and JCK classes. Replay compilation does not work because there's a lot of inlining of generated bytecode (jdk/proxy1671/$Proxy17271 ...).
25-07-2023