JDK-8305185 : C2 failed "assert(false) failed: Can't determine return type."
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 21,22,23
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2023-03-29
  • Updated: 2024-09-16
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8305740 - C2: add print statements to assert: Can't determine return type.
Relates :  
JDK-8303951 - Add asserts before record_method_not_compilable where possible
Sub Tasks
JDK-8334442 :  
Temporarily disable return type assertion to reduce noise in testing - Resolved
Description
The following test failed in the JDK21 CI:

serviceability/attach/ConcAttachTest.java

Here's a snippet from the log file:

----------stdout:(19/1638)----------
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/System/Volumes/Data/mesos/work_dir/slaves/91e16c40-06d4-468a-9fc3-7198a5bb7d5a-S84880/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/4352da35-11ea-41df-81aa-3ed43a1cce91/runs/61b4e10e-8005-4b5f-8760-59848362ec2c/workspace/open/src/hotspot/share/opto/parse1.cpp:1051), pid=87609, tid=36867
#  assert(false) failed: Can't determine return type.
#
# JRE version: Java(TM) SE Runtime Environment (21.0+16) (fastdebug build 21-ea+16-LTS-1273)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 21-ea+16-LTS-1273, compiled mode, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
# Core dump will be written. Default location: core.87609
#
# An error report file with more information is saved as:
# /System/Volumes/Data/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S26911/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/c56af949-550d-44e4-a46c-329383f91871/runs/c355f6f2-bfc7-4deb-82b9-73c128844a93/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_serviceability/scratch/1/hs_err_pid87609.log
#
# Compiler replay data is saved as:
# /System/Volumes/Data/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S26911/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/c56af949-550d-44e4-a46c-329383f91871/runs/c355f6f2-bfc7-4deb-82b9-73c128844a93/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_serviceability/scratch/1/replay_pid87609.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
result: Error. Agent communication error: java.io.EOFException; check console log for any additional details


Here's the crashing thread's stack:

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

Current thread (0x00007fc37b89d610):  JavaThread "C2 CompilerThread1" daemon [_thread_in_native, id=36867, stack(0x0000700011920000,0x0000700011a20000)]


Current CompileTask:
C2:  83329 8664    b        sun.jvmstat.perfdata.monitor.AbstractPerfDataBufferPrologue::majorVersionBuffer (24 bytes)

Stack: [0x0000700011920000,0x0000700011a20000],  sp=0x0000700011a1d8f0,  free space=1014k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x129324b]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x5cb  (parse1.cpp:1051)
V  [libjvm.dylib+0x129393b]  VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x3b
V  [libjvm.dylib+0x6dd145]  report_vm_error(char const*, int, char const*, char const*, ...)+0xf5
V  [libjvm.dylib+0xf8ec57]  Parse::do_exits()+0x667
V  [libjvm.dylib+0xf89fb8]  Parse::Parse(JVMState*, ciMethod*, float)+0xc18
V  [libjvm.dylib+0x52844a]  ParseGenerator::generate(JVMState*)+0xaa
V  [libjvm.dylib+0x644357]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1777
V  [libjvm.dylib+0x526157]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x167
V  [libjvm.dylib+0x663119]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x629
V  [libjvm.dylib+0x662858]  CompileBroker::compiler_thread_loop()+0x2a8
V  [libjvm.dylib+0xa1cc7f]  JavaThread::thread_main_inner()+0x1ff
V  [libjvm.dylib+0x11db4d7]  Thread::call_run()+0x177
V  [libjvm.dylib+0xf57cef]  thread_native_entry(Thread*)+0x14f
C  [libsystem_pthread.dylib+0x6109]  _pthread_start+0x94
C  [libsystem_pthread.dylib+0x1b8b]  thread_start+0xf
Comments
Moving this to tbd now that the assert has been disabled.
16-09-2024
[~dholmes] As I mentioned above, JDK-8293980 seems to trigger this. The failures reported in this bug might well have different root causes though. We disabled the assert with JDK-8334442 for now.
19-06-2024
This now seems to be failing very regularly. I guess the problme causing this is actually new compared to the original reports?
19-06-2024
I can reproduce this reliably by running test/jdk/java/util/jar/JarFile/jarVerification/MultiProviderTest.java with "-Xcomp -XX:-TieredCompilation -XX:CompileCommand=quiet -XX:CompileCommand=compileonly,sun.net.www.protocol.file.Handler::*" since JDK-8293980 which most likely only triggered an existing issue. # exit control 1846 IfFalse === 1844 [[ 1940 ]] #0 !jvms: FileURLConnection::<init> @ bci:34 (line 63) Handler::createFileURLConnection @ bci:6 (line 102) Handler::openConnection @ bci:54 (line 70) 1921 Region === 1921 1902 1853 [[ 1921 1940 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 ]] !jvms: FileURLConnection::<init> @ bci:34 (line 63) Handler::createFileURLConnection @ bci:6 (line 102) Handler::openConnection @ bci:54 (line 70) 1940 Region === 1940 1921 1846 [[ 1940 770 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 737 15 ]] !jvms: FileURLConnection::<init> @ bci:34 (line 63) Handler::createFileURLConnection @ bci:6 (line 102) Handler::openConnection @ bci:54 (line 70) 15 Region === _ 1940 [[ 2050 2049 16 17 19 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 14 ]] # ret phi type top# ret phi 0 Root === 0 37 107 245 260 439 644 1013 1031 [[ 0 1 3 24 32 39 41 43 59 74 92 109 133 154 170 196 208 240 254 255 261 262 304 353 355 358 359 369 370 371 373 403 423 434 440 441 442 465 468 520 521 522 528 530 532 585 632 727 745 746 806 845 852 859 860 863 881 954 970 1026 997 1008 1066 1074 1075 1078 1100 1127 1131 1176 1178 1179 1182 1183 1186 1188 1191 1246 1285 1345 1394 1446 1506 1582 1585 1637 1697 1759 1763 1767 1772 1776 1779 1831 1891 ]] 1 Con === 0 [[ ]] #top # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/workspace/open/src/hotspot/share/opto/parse1.cpp:1069), pid=3611237, tid=3611253 # assert(false) failed: Can't determine return type. # # JRE version: Java(TM) SE Runtime Environment (24.0+3) (fastdebug build 24-ea+3-177) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 24-ea+3-177, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x14dfe67] Parse::do_exits()+0x1477
17-06-2024
Weird that this now reproduced twice with the same build and the same test but on completely different architectures (AArch64 and x64). Unfortunately, the replay file does not reproduce the issue. Trying to re-run the test now. Update: It *does* reproduce ~50% with that exact same build and test.
17-06-2024
Two new failures in our CI today Test: java/util/jar/JarFile/jarVerification/MultiProviderTest.java
17-06-2024
Yes. Right, it will most likely generate a large file. Thanks for giving it a try!
06-06-2024
It seems to happen always in the same method on AIX. I assume you mean: -XX:CompileCommand="option,jdk.internal.foreign.SystemLookup::lambda$makeSystemLookup$1,intx,IGVPrintLevel,6" -XX:PrintIdealGraphFile=ideal.xml We can try. Level 6 may generate a huge file, right?
06-06-2024
If it's always the same method that is failing, you could try dumping the graph during parsing via -XX:CompileCommand=igvprintlevel,Class::method,6 so that we can inspect it in IGVN.
05-06-2024
In case you have a patch to e.g. get more information in the error case, we could add this to our build/test queue.
04-06-2024
> Okay, any chance you could try and extract a reproducer that you could share from that? I think this will be hard, because I am only aware of jars from this application test we use, and it is a larger test package.
04-06-2024
Okay, any chance you could try and extract a reproducer that you could share from that?
03-06-2024
> That just looks like a broken graph, not much we can do here without a reproducer. [~mbaesken], [~mdoerr], can you reproduce the issue? Is there a specific test / configuration that triggers it? We see the issue from time to time on AIX in an internal (not public) JUNIT test.
31-05-2024
That just looks like a broken graph, not much we can do here without a reproducer. [~mbaesken], [~mdoerr], can you reproduce the issue? Is there a specific test / configuration that triggers it?
30-05-2024
AIX shows the issue today : # Internal Error (/priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-dbg/jdk/src/hotspot/share/opto/parse1.cpp:1072), pid=4915938, tid=3599 # assert(false) failed: Can't determine return type. Current CompileTask: C2:137431 67303 4 jdk.internal.foreign.SystemLookup::lambda$makeSystemLookup$1 (10 bytes) Stack: [0x0000000115110000,0x000000011550d888], sp=0x0000000115509fe0, free space=4071k No context given, using current context. Native frame: iar: 0x090000000b9bc8f4 libjvm.so::AixNativeCallstack::print_callstack_for_context(outputStream*, ucontext_t const*, bool, char*, unsigned long)+0x4cc (C++ uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:5 parmsonstk:1) lr: 0x090000000b73d9b4 libjvm.so::fdStream::write(char const*, unsigned long)+0x44 (C++ uses_alloca saves_lr stores_bc gpr_saved:4 fixedparms:3 parmsonstk:1) sp: 0x00000001155092a0 (base - 0x45E8) rtoc: 0x08001000a03d1cc8 |---stackaddr----| |----lrsave------|: <function name> 0x0000000115509690 - 0x090000000b9bc3b4 libjvm.so::os::Aix::platform_print_native_stack(outputStream*, void const*, char*, int, unsigned char*&)+0x24 (C++ uses_alloca saves_lr stores_bc gpr_saved:1 fixedparms:5 parmsonstk:1) 0x0000000115509710 - 0x090000000b752588 libjvm.so::VMError::report(outputStream*, bool)+0x1c0c (C++ fp_present uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:2 parmsonstk:1) 0x0000000115509ff0 - 0x090000000b73cdc8 libjvm.so::VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x7cc (C++ uses_alloca saves_lr stores_bc gpr_saved:18 fixedparms:8 parmsonstk:1) 0x000000011550a1e0 - 0x090000000b73c5b0 libjvm.so::VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, char*)+0x58 (C++ uses_alloca saves_lr stores_bc gpr_saved:2 fixedparms:7 parmsonstk:1) 0x000000011550a280 - 0x090000000b73c290 libjvm.so::report_vm_error(char const*, int, char const*, char const*, ...)+0x8c (C++ uses_alloca saves_lr stores_bc gpr_saved:5 fixedparms:4 parmsonstk:1) 0x000000011550a320 - 0x090000000c633b28 libjvm.so::Parse::do_exits()+0x1594 (C++ fp_present uses_alloca saves_cr saves_lr stores_bc gpr_saved:10 fixedparms:1 parmsonstk:1) 0x000000011550a440 - 0x090000000c55598c libjvm.so::Parse::Parse(JVMState*, ciMethod*, float)+0xd58 (C++ fp_present uses_alloca saves_cr saves_lr stores_bc fpr_saved:2 gpr_saved:13 fixedparms:3 floatparms:1 parmsonstk:1) 0x000000011550a530 - 0x090000000c554a20 libjvm.so::ParseGenerator::generate(JVMState*)+0x134 (C++ fp_present uses_alloca saves_lr stores_bc gpr_saved:5 fixedparms:2 parmsonstk:1) 0x000000011550a740 - 0x090000000c608904 libjvm.so::PredictedCallGenerator::generate(JVMState*)+0x26c (C++ fp_present uses_alloca saves_lr stores_bc gpr_saved:10 fixedparms:2 parmsonstk:1) 0x000000011550a8a0 - 0x090000000c56dfd8 libjvm.so::Parse::do_call()+0xb54 (C++ fp_present uses_alloca saves_cr saves_lr stores_bc gpr_saved:14 fixedparms:1 parmsonstk:1) 0x000000011550a9d0 - 0x090000000c56a87c libjvm.so::Parse::do_one_bytecode()+0x1f8 (C++ fp_present uses_alloca saves_lr stores_bc gpr_saved:10 fixedparms:1 parmsonstk:1) 0x000000011550aba0 - 0x090000000c56a028 libjvm.so::Parse::do_one_block()+0x5a4 (C++ uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:1 parmsonstk:1) 0x000000011550acc0 - 0x090000000c568dd0 libjvm.so::Parse::do_all_blocks()+0x574 (C++ uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:1 parmsonstk:1) 0x000000011550adc0 - 0x090000000c55595c libjvm.so::Parse::Parse(JVMState*, ciMethod*, float)+0xd28 (C++ fp_present uses_alloca saves_cr saves_lr stores_bc fpr_saved:2 gpr_saved:13 fixedparms:3 floatparms:1 parmsonstk:1) 0x000000011550aeb0 - 0x090000000c554a20 libjvm.so::ParseGenerator::generate(JVMState*)+0x134 (C++ fp_present uses_alloca saves_lr stores_bc gpr_saved:5 fixedparms:2 parmsonstk:1) 0x000000011550b0c0 - 0x090000000c549ad4 libjvm.so::Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1020 (C++ fp_present uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:6 parmsonstk:1) 0x000000011550bd40 - 0x090000000c76ad60 libjvm.so::C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x25c (C++ uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:6 parmsonstk:1) 0x000000011550ca80 - 0x090000000ba9a970 libjvm.so::CompileBroker::invoke_compiler_on_method(CompileTask*)+0xcf4 (C++ fp_present uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:1 parmsonstk:1) 0x000000011550d200 - 0x090000000ba6f44c libjvm.so::CompileBroker::compiler_thread_loop()+0x4c0 (C++ fp_present uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 parmsonstk:1) 0x000000011550d450 - 0x090000000ba6ef0c libjvm.so::CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x58 (C++ uses_alloca saves_lr stores_bc gpr_saved:1 fixedparms:2 parmsonstk:1) 0x000000011550d4d0 - 0x090000000b9ad70c libjvm.so::JavaThread::thread_main_inner()+0x1f8 (C++ uses_alloca saves_lr stores_bc gpr_saved:4 fixedparms:1 parmsonstk:1) 0x000000011550d5a0 - 0x090000000b9ab7e4 libjvm.so::JavaThread::run()+0x214 (C++ uses_alloca saves_lr stores_bc gpr_saved:5 fixedparms:1 parmsonstk:1) 0x000000011550d640 - 0x090000000b85a9c0 libjvm.so::Thread::call_run()+0x128 (C++ uses_alloca saves_lr stores_bc gpr_saved:3 fixedparms:1 parmsonstk:1) 0x000000011550d6d0 - 0x090000000b859f20 libjvm.so::thread_native_entry(Thread*)+0x214 (C++ uses_alloca saves_lr stores_bc gpr_saved:10 fixedparms:1 parmsonstk:1) 0x000000011550d7a0 - 0x090000000056204c libpthreads.a::_pthread_body+0xec (C saves_lr stores_bc gpr_saved:1 fixedparms:1 ) 0x000000011550d820 - 0x0000000000000000
29-05-2024
... and one more today in JDK 23: # Can't determine return type. # exit control 490 CatchProj === 489 [[ 335 498 ]] #0@bci -1 !jvms: RawNativeLibraries::load @ bci:23 (line 129) RawNativeLibraries::load @ bci:24 (line 95) SystemLookup::lambda$makeSystemLookup$1 @ bci:6 (line 66) 462 IfFalse === 460 [[ 335 465 ]] #0 !jvms: RawNativeLibraries::load @ bci:13 (line 126) RawNativeLibraries::load @ bci:24 (line 95) SystemLookup::lambda$makeSystemLookup$1 @ bci:6 (line 66) 335 Region === 335 462 490 [[ 335 339 336 337 85 ]] !jvms: RawNativeLibraries::load @ bci:24 (line 95) SystemLookup::lambda$makeSystemLookup$1 @ bci:6 (line 66) 85 Region === _ 335 [[ 89 87 86 84 ]] !jvms: SystemLookup::lambda$makeSystemLookup$1 @ bci:6 (line 66) # ret phi type top# ret phi 0 Root === 0 40 72 300 318 480 [[ 0 1 3 20 21 22 25 35 43 59 67 74 77 93 94 125 141 144 146 149 150 180 199 252 279 284 295 313 343 344 395 ]] 1 Con === 0 [[ ]] #top
27-05-2024
The assertion has showed up in JDK 23 today. # Can't determine return type. # exit control 490 CatchProj === 489 [[ 335 498 ]] #0@bci -1 !jvms: RawNativeLibraries::load @ bci:23 (line 129) RawNativeLibraries::load @ bci:24 (line 95) SystemLookup::lambda$makeSystemLookup$1 @ bci:6 (line 66) 462 IfFalse === 460 [[ 335 465 ]] #0 !jvms: RawNativeLibraries::load @ bci:13 (line 126) RawNativeLibraries::load @ bci:24 (line 95) SystemLookup::lambda$makeSystemLookup$1 @ bci:6 (line 66) 335 Region === 335 462 490 [[ 335 339 336 337 85 ]] !jvms: RawNativeLibraries::load @ bci:24 (line 95) SystemLookup::lambda$makeSystemLookup$1 @ bci:6 (line 66) 85 Region === _ 335 [[ 89 87 86 84 ]] !jvms: SystemLookup::lambda$makeSystemLookup$1 @ bci:6 (line 66) # ret phi type top# ret phi 0 Root === 0 40 72 300 318 480 [[ 0 1 3 20 21 22 25 35 43 59 67 74 77 93 94 125 141 144 146 149 150 180 199 252 279 284 295 313 343 344 395 ]] 1 Con === 0 [[ ]] #top
03-05-2024
Newest failure with JDK 21.0.2+4: # Can't determine return type. # exit control 919 MemBarRelease === 910 1 696 1 1 688 [[ 920 921 ]] !jvms: DirectConstructorHandleAccessor::<init> @ bci:-1 (line 50) DirectConstructorHandleAccessor::constructorAccessor @ bci:6 (line 40) MethodHandleAccessorFactory::newConstructorAccessor @ bci:70 (line 115) 920 Proj === 919 [[ 660 953 13 ]] #0 !jvms: DirectConstructorHandleAccessor::<init> @ bci:-1 (line 50) DirectConstructorHandleAccessor::constructorAccessor @ bci:6 (line 40) MethodHandleAccessorFactory::newConstructorAccessor @ bci:70 (line 115) 13 Region === _ 920 [[ 17 15 14 12 ]] # ret phi type top# ret phi 0 Root === 0 65 79 149 310 346 380 473 523 556 618 757 962 [[ 0 1 3 35 36 60 66 74 81 84 100 115 116 117 144 252 257 258 259 283 312 330 348 382 452 461 668 669 742 765 766 767 769 799 821 822 823 825 830 832 836 887 957 ]] 1 Con === 0 [[ ]] #top # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (workspace/open/src/hotspot/share/opto/parse1.cpp:1060), pid=3702179, tid=3702202 # assert(false) failed: Can't determine return type. # I tried replay compilation on the same machine and with the same build. No success.
03-11-2023
No failure since July 2023
19-10-2023
I'm leaving this for someone else for now, I'm working on too many other issues for the moment. Sadly I've not been able to reproduce it yet. Good luck!
26-06-2023
Here's the crashing thread's stack from the jdk-22+2-31-tier8 sighting: vmTestbase/runtime/pcl/bootstrap/stress/forName/dynamic-init/abstract/TestDescription.java --------------- T H R E A D --------------- Current thread (0x00007fd5c14e6be0): JavaThread "C2 CompilerThread1" daemon [_thread_in_native, id=20700, stack(0x00007fd5b91d2000,0x00007fd5b92d3000) (1028K)] Current CompileTask: C2: 31802 5546 !b 4 jdk.internal.reflect.MethodHandleAccessorFactory::newConstructorAccessor (84 bytes) Stack: [0x00007fd5b91d2000,0x00007fd5b92d3000], sp=0x00007fd5b92cf9e0, free space=1014k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x14defaa] Parse::do_exits()+0x11fa (parse1.cpp:1060) V [libjvm.so+0x14e7d1d] Parse::Parse(JVMState*, ciMethod*, float)+0xbad (parse1.cpp:627) V [libjvm.so+0x84d358] ParseGenerator::generate(JVMState*)+0x168 (callGenerator.cpp:99) V [libjvm.so+0x9f1046] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x16d6 (compile.cpp:769) V [libjvm.so+0x84b214] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x3c4 (c2compiler.cpp:118) V [libjvm.so+0x9fd410] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xa00 (compileBroker.cpp:2265) V [libjvm.so+0x9fe298] CompileBroker::compiler_thread_loop()+0x618 (compileBroker.cpp:1944) V [libjvm.so+0xeb65bc] JavaThread::thread_main_inner()+0xcc (javaThread.cpp:719) V [libjvm.so+0x1795f2a] Thread::call_run()+0xba (thread.cpp:217) V [libjvm.so+0x14963ec] thread_native_entry(Thread*)+0x11c (os_linux.cpp:778)
16-06-2023
Ok, we hit it another 2 times in testing. This is the print statements: # Can't determine return type. # exit control 909 MemBarRelease === 876 1 788 1 1 780 [[ 910 911 ]] !jvms: DirectConstructorHandleAccessor::<init> @ bci:-1 (line 50) DirectConstructorHandleAccessor::constructorAccessor @ bci:6 (line 40) MethodHandleAccessorFactory::newConstructorAccessor @ bci:70 (line 115) 910 Proj === 909 [[ 751 932 13 ]] #0 !jvms: DirectConstructorHandleAccessor::<init> @ bci:-1 (line 50) DirectConstructorHandleAccessor::constructorAccessor @ bci:6 (line 40) MethodHandleAccessorFactory::newConstructorAccessor @ bci:70 (line 115) 13 Region === _ 910 [[ 17 15 14 12 ]] # ret phi type top # ret phi 0 Root === 0 65 79 149 310 346 380 473 523 556 618 882 941 [[ 0 1 3 35 36 60 66 74 81 84 100 115 116 117 144 252 257 258 259 283 312 330 348 382 452 461 760 761 821 823 826 827 867 898 900 936 ]] 1 Con === 0 [[ ]] #top Indeed, the control is live but the return phi has turned "top".
22-05-2023
Updated ILW = Debug assert in C2 (bailout in product), rare and intermittent, disable compilation of affected method = MLM = P4
03-05-2023
Moving this to JDK 22 for now. Please update the fix version if a patch is ready in time for JDK 21.
03-05-2023
I have now added some print statements in JDK-8303951. But we have not had any new failures reported for a 20 days. I will wait until we have new failure reports.
24-04-2023
By now I have 4 failures reported. They fail for these methods: jdk.internal.reflect.MethodHandleAccessorFactory::newConstructorAccessor java.util.concurrent.ForkJoinTask::adapt sun.jvmstat.perfdata.monitor.AbstractPerfDataBufferPrologue::majorVersionBuffer sun.jvmstat.perfdata.monitor.AbstractPerfDataBufferPrologue::majorVersionBuffer Can't see a clear commonality between these though.
05-04-2023
I'm looking into it. Seems not to reproduce on my machine. I'm trying to get it to reproduce on the testing infrastructure. Preliminary comment: I inserted the assert - to prevent silent bailouts where there are bugs. And the assert seemed not to trigger. Now it triggered in a high tier. We need to analyze if this is an expected bailout, or indeed a bug.
04-04-2023
ILW = assert; one test, debug build; no workaround = MMH = P3
30-03-2023
I believe this assert was introduced by JDK-8303951. [~epeter], please take a look.
30-03-2023