JDK-8310844 : [AArch64] C1 compilation fails because monitor offset in OSR buffer is too large for immediate
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17.0.6,20,21,22,23
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,os_x
  • CPU: aarch64
  • Submitted: 2023-06-24
  • Updated: 2025-02-12
  • Resolved: 2024-01-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 17 JDK 21 JDK 22 JDK 23
17.0.11Fixed 21.0.3-oracleFixed 22Fixed 23 b05Fixed
Related Reports
Relates :  
JDK-8330806 - test/hotspot/jtreg/compiler/c1/TestLargeMonitorOffset.java fails on ARM32
Relates :  
JDK-8322996 - BoxLockNode creation fails with assert(reg < CHUNK_SIZE) failed: sanity
Relates :  
JDK-8320682 - [AArch64] C1 compilation fails with "Field too big for insn"
Relates :  
JDK-8287349 - AArch64: Merge LDR instructions to improve C1 OSR performance
Description
Passing on a report from: https://github.com/adoptium/adoptium-support/issues/810

In certain cases - when starting an application it crashes with a bug that looks very similar to something that appears to have been fixed in one of the previous releases, i.e.:
Internal Error (assembler_aarch64.hpp:267), pid=2929, tid=25347

Hard to reproduce exactly when it happens - sometime during the application startup.

What Java Version are you using?
openjdk version "17.0.7" 2023-04-18 OpenJDK Runtime Environment Temurin-17.0.7+7 (build 17.0.7+7) OpenJDK 64-Bit Server VM Temurin-17.0.7+7 (build 17.0.7+7, mixed mode)

What is your operating system and platform?
MacOS Ventura 13.4, ARM64 / M1

How did you install Java?
Through homebrew.

Did it work before?
Hard to say as this is a new application - never had the same conditions before.

Did you test with the latest update version?
Yes.

Did you test with other Java versions?
Yes, with Zulu 17 as well as Oracle, both crash.

Relevant log output
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (assembler_aarch64.hpp:267), pid=2929, tid=25347
#  guarantee(chk == -1 || chk == 0) failed: Field too big for insn
#
# JRE version: OpenJDK Runtime Environment Temurin-17.0.7+7 (17.0.7+7) (build 17.0.7+7)
# Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.7+7 (17.0.7+7, mixed mode, emulated-client, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   https://github.com/adoptium/adoptium-support/issues
#

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

Command Line: -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:64579,suspend=y,server=n -XX:TieredStopAtLevel=1 -Dspring.output.ansi.enabled=always -Dcom.sun.management.jmxremote -Dspring.jmx.enabled=true -Dspring.liveBeansView.mbeanDomain -Dspring.application.admin.enabled=true -Dmanagement.endpoints.jmx.exposure.include=* -javaagent:/Users/bos/Library/Caches/JetBrains/IntelliJIdea2023.1/captureAgent/debugger-agent.jar -Dfile.encoding=UTF-8 care.better.demographics.DemographicsApplicationKt --spring.config.additional-location=./conf/

Host: "MacBookPro18,3" arm64, 10 cores, 16G, Darwin 22.5.0, macOS 13.4 (22F66)
Time: Fri Jun  2 13:59:01 2023 CEST elapsed time: 21.592415 seconds (0d 0h 0m 21s)

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

Current thread (0x000000011e018200):  JavaThread "C1 CompilerThread1" daemon [_thread_in_native, id=25347, stack(0x000000016ef30000,0x000000016f133000)]


Current CompileTask:
C1:  21592 18532 %s    1       care.better.demographics.index.indexing.param.DatabaseAwareSearchParameterRetriever::syncSearchParametersIfNecessary @ 89 (1754 bytes)

Stack: [0x000000016ef30000,0x000000016f133000],  sp=0x000000016f1319a0,  free space=2054k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0xa1a1d8]  VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x490
V  [libjvm.dylib+0xa1a95c]  VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, char*)+0x40
V  [libjvm.dylib+0x2c5188]  report_vm_error(char const*, int, char const*, char const*, ...)+0x78
V  [libjvm.dylib+0x872478]  Address::encode_pair(Instruction_aarch64*) const+0x128
V  [libjvm.dylib+0x8722fc]  Assembler::ld_st1(int, int, int, int, RegisterImpl*, RegisterImpl*, Address, bool)+0x20c
V  [libjvm.dylib+0x1a320c]  LIR_Assembler::osr_entry()+0x1e8
V  [libjvm.dylib+0x1a10d0]  LIR_Assembler::emit_lir_list(LIR_List*)+0x9c
V  [libjvm.dylib+0x1a1178]  LIR_Assembler::emit_code(BlockList*)+0x74
V  [libjvm.dylib+0x17333c]  Compilation::emit_code_body()+0xe0
V  [libjvm.dylib+0x1739e4]  Compilation::compile_java_method()+0x354
V  [libjvm.dylib+0x173c1c]  Compilation::compile_method()+0x124
V  [libjvm.dylib+0x173fb0]  Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x19c
V  [libjvm.dylib+0x1751cc]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x5c
V  [libjvm.dylib+0x2a0c7c]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x528
V  [libjvm.dylib+0x2a06bc]  CompileBroker::compiler_thread_loop()+0x440
V  [libjvm.dylib+0x9ac384]  JavaThread::thread_main_inner()+0x150
V  [libjvm.dylib+0x9aaa0c]  Thread::call_run()+0xe0
V  [libjvm.dylib+0x7ca4c8]  thread_native_entry(Thread*)+0x158
C  [libsystem_pthread.dylib+0x6fa8]  _pthread_start+0x94

(truncated to get under 64k limit)
Comments
[jdk17u-fix-request] Approval Request from Dmitry Chuyko Clean backport to fix 1.5 yrs old regression. Effectively reverts JDK-8293671. New regression test works.
09-01-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/2117 Date: 2024-01-09 15:10:52 +0000
09-01-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk22/pull/38 Date: 2024-01-08 09:36:25 +0000
08-01-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk21u-dev/pull/137 Date: 2024-01-08 09:14:24 +0000
08-01-2024
[jdk21u-fix-request] Approval Request from Aleksey Shipilëv Clean backport to fix 1.5 yrs old regression. Effectively reverts JDK-8287349. New regression test works.
08-01-2024
Changeset: ade21a96 Author: Tobias Hartmann <thartmann@openjdk.org> Date: 2024-01-05 13:48:31 +0000 URL: https://git.openjdk.org/jdk/commit/ade21a965f8a5fc889cd48bba76fad507bdeddf5
05-01-2024
Found two unrelated bugs when working on the reproducer: JDK-8322992 (javac) and JDK-8322996 (C2).
04-01-2024
We found this in our own testing (thanks to [~mschoene] for reporting!) and I was able to extract a simple reproducer (see attached Test2.java). java -Xbatch -XX:CompileCommand=compileonly,Test2::* -XX:CompileCommand=quiet -XX:+PrintCompilation Test2.java # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/opt/mach5/mesos/work_dir/slaves/afbc6042-3a24-4198-9369-18c663a3f74c-S29988/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/1497bb84-eae7-47a0-9606-31ab1a44332c/runs/671d5cb7-8e32-4061-9b1b-5d6b408baf34/workspace/open/src/hotspot/cpu/aarch64/assembler_aarch64.hpp:265), pid=1055310, tid=1055325 # guarantee(chk == -1 || chk == 0) failed: Field too big for insn # # JRE version: Java(TM) SE Runtime Environment (22.0+21) (fastdebug build 22-ea+21-1619) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-ea+21-1619, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) # Problematic frame: # V [libjvm.so+0x6b1c14] LIR_Assembler::osr_entry()+0x800 # Current CompileTask: C1:1683 81 % !b 3 Test2::test @ 13 (54 bytes) Stack: [0x0000ffff6c540000,0x0000ffff6c740000], sp=0x0000ffff6c73bbc0, free space=2030k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x6b1c14] LIR_Assembler::osr_entry()+0x800 (assembler_aarch64.hpp:265) V [libjvm.so+0x6ae444] LIR_Assembler::emit_lir_list(LIR_List*)+0xe4 V [libjvm.so+0x6af144] LIR_Assembler::emit_code(BlockList*)+0x264 V [libjvm.so+0x659160] Compilation::emit_code_body()+0x150 V [libjvm.so+0x659764] Compilation::compile_java_method()+0x3b0 V [libjvm.so+0x659fa8] Compilation::compile_method()+0x168 V [libjvm.so+0x65a6b8] Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x248 V [libjvm.so+0x65c3d8] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xd8 V [libjvm.so+0x91e8c4] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x8e4 V [libjvm.so+0x91f3dc] CompileBroker::compiler_thread_loop()+0x5bc V [libjvm.so+0xdba010] JavaThread::thread_main_inner()+0xec V [libjvm.so+0x16055a4] Thread::call_run()+0xb0 V [libjvm.so+0x136df08] thread_native_entry(Thread*)+0x138 C [libpthread.so.0+0x7950] start_thread+0x190 The problem is that the slot offset for the monitor in the OSR buffer is too large for the 'ldp' immediate in 'LIR_Assembler::osr_entry'. This is a regression from JDK-8287349 in JDK 20 b03 (backported to JDK 17.0.6).
04-01-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/17266 Date: 2024-01-04 12:39:18 +0000
04-01-2024
Also from the OP "It's been 5 days, and we've continued to see no crashes on the hosts running the code with the problematic method rewritten. Similarly we've seen no crashes with -XX:CICompilerCount=2 -XX:CompilationMode=high-only."
22-11-2023
The user was able to extract a backtrace from a core dump: #0 0x0000ffffb0b43274 in raise () from /lib64/libc.so.6 #1 0x0000ffffb0b2da2c in abort () from /lib64/libc.so.6 #2 0x0000ffffb0380c28 in os::abort (dump_core=true, siginfo=<optimized out>, context=<optimized out>) at src/hotspot/os/posix/os_posix.cpp:2082 #3 0x0000ffffb05ffc1c in VMError::report_and_die (id=id@entry=-536870912, message=message@entry=0xffffb06843d8 "guarantee(chk == -1 || chk == 0) failed", detail_fmt=detail_fmt@entry=0xffffb067b5e8 "Field too big for insn", detail_args=<error reading variable: Cannot access memory at address 0x8>, thread=0xffffa881c150, pc=pc@entry=0x0, siginfo=siginfo@entry=0x0, context=context@entry=0xffffb0a8c260 <g_stored_assertion_context>, filename=filename@entry=0xffffb067b628 "src/hotspot/cpu/aarch64/assembler_aarch64.hpp", lineno=lineno@entry=267, size=size@entry=0) at src/hotspot/share/utilities/vmError.cpp:1816 #4 0x0000ffffb0600670 in VMError::report_and_die (thread=<optimized out>, context=context@entry=0xffffb0a8c260 <g_stored_assertion_context>, filename=filename@entry=0xffffb067b628 "src/hotspot/cpu/aarch64/assembler_aarch64.hpp", lineno=lineno@entry=267, message=message@entry=0xffffb06843d8 "guarantee(chk == -1 || chk == 0) failed", detail_fmt=detail_fmt@entry=0xffffb067b5e8 "Field too big for insn", detail_args=<error reading variable: Cannot access memory at address 0xffffffffffffffff>) at src/hotspot/share/utilities/vmError.cpp:1509 #5 0x0000ffffafddcb38 in report_vm_error (file=file@entry=0xffffb067b628 "src/hotspot/cpu/aarch64/assembler_aarch64.hpp", line=line@entry=267, error_msg=error_msg@entry=0xffffb06843d8 "guarantee(chk == -1 || chk == 0) failed", detail_fmt=detail_fmt@entry=0xffffb067b5e8 "Field too big for insn") at src/hotspot/share/runtime/thread.hpp:692 #6 0x0000ffffafc880f8 in Instruction_aarch64::sf (lsb=15, msb=21, val=118, this=0xffff6ae0c450) at src/hotspot/cpu/aarch64/assembler_aarch64.hpp:267 #7 Address::encode_pair (i=0xffff6ae0c450, this=<synthetic pointer>) at src/hotspot/cpu/aarch64/assembler_aarch64.hpp:567 #8 Assembler::ld_st1 (no_allocate=false, adr=..., Rt2=<optimized out>, Rt1=<optimized out>, L=1, V=0, p1=5, opc=2, this=<optimized out>) at src/hotspot/cpu/aarch64/assembler_aarch64.hpp:1414 #9 Assembler::ldp (adr=..., Rt2=<optimized out>, Rt1=<optimized out>, this=<optimized out>) at src/hotspot/cpu/aarch64/assembler_aarch64.hpp:1428 #10 LIR_Assembler::osr_entry (this=0xffff6ae0c560) at src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp:285 #11 0x0000ffffafc85994 in LIR_Assembler::emit_lir_list (this=0xffff6ae0c560, list=0xaaaaf600edb0) at src/hotspot/share/c1/c1_LIRAssembler.cpp:302 #12 0x0000ffffafc85b8c in LIR_Assembler::emit_block (block=0xffff64ad8110, this=0xffff6ae0c560) at src/hotspot/share/c1/c1_Instruction.hpp:1722 #13 LIR_Assembler::emit_code (this=this@entry=0xffff6ae0c560, hir=0xaaaaf68921e0) at src/hotspot/share/c1/c1_LIRAssembler.cpp:226 #14 0x0000ffffafc56560 in Compilation::emit_code_body (this=this@entry=0xffff6ae0d020) at src/hotspot/share/c1/c1_IR.hpp:321 #15 0x0000ffffafc56964 in Compilation::compile_java_method (this=this@entry=0xffff6ae0d020) at src/hotspot/share/c1/c1_Compilation.cpp:401 #16 0x0000ffffafc56b70 in Compilation::compile_method (this=0xffff6ae0d020) at src/hotspot/share/c1/c1_Compilation.cpp:457 #17 Compilation::compile_method (this=0xffff6ae0d020) at src/hotspot/share/c1/c1_Compilation.cpp:426 #18 0x0000ffffafc56ee8 in Compilation::Compilation (this=0xffff6ae0d020, compiler=<optimized out>, env=<optimized out>, method=0xaaaaf6c408a0, osr_bci=<optimized out>, buffer_blob=<optimized out>, install_code=<optimized out>, directive=<optimized out>) at src/hotspot/share/c1/c1_Compilation.cpp:581 #19 0x0000ffffafc57a04 in Compiler::compile_method (this=<optimized out>, env=<optimized out>, method=<optimized out>, entry_bci=<optimized out>, install_code=<optimized out>, directive=<optimized out>) at src/hotspot/share/c1/c1_Compiler.cpp:248 #20 0x0000ffffafdb18ac in CompileBroker::invoke_compiler_on_method (task=task@entry=0xffffa88296b0) at src/hotspot/share/compiler/compileBroker.cpp:2330 #21 0x0000ffffafdb231c in CompileBroker::compiler_thread_loop () at src/hotspot/share/compiler/compileBroker.cpp:2001 #22 0x0000ffffb0587020 in JavaThread::thread_main_inner (this=0xffffa881c150) at src/hotspot/share/runtime/thread.hpp:1123 #23 0x0000ffffb058c0ec in Thread::call_run (this=0xffffa881c150) at src/hotspot/share/runtime/thread.cpp:395 #24 0x0000ffffb0375dfc in thread_native_entry (thread=0xffffa881c150) at src/hotspot/os/linux/os_linux.cpp:725 #25 0x0000ffffb0cab8b8 in start_thread () from /lib64/libpthread.so.0 #26 0x0000ffffb0b30afc in thread_start () from /lib64/libc.so.6
22-11-2023
Had a separate C1 crash on Linux AArch64 (17.0.9+9 this time) around the same area (`LIR_Assembler::osr_entry()`). https://github.com/adoptium/adoptium-support/issues/951 for the full details. --------------- T H R E A D --------------- Current thread (0x0000ffffa881c260): JavaThread "C1 CompilerThread0" daemon [_thread_in_native, id=3720547, stack(0x0000ffff6ae10000,0x0000ffff6b00e000)] Current CompileTask: C1:22791144 31861 %s! 3 org.apache.hadoop.hbase.regionserver.MetricsRegionServerWrapperImpl$RegionServerMetricsWrapperRunnable::run @ 568 (2086 bytes) Stack: [0x0000ffff6ae10000,0x0000ffff6b00e000], sp=0x0000ffff6b00b3b0, free space=2028k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x4880f0] LIR_Assembler::osr_entry()+0x200 V [libjvm.so+0x485994] LIR_Assembler::emit_lir_list(LIR_List*)+0x90 V [libjvm.so+0x485b8c] LIR_Assembler::emit_code(BlockList*)+0x5c V [libjvm.so+0x456560] Compilation::emit_code_body()+0x110 V [libjvm.so+0x456964] Compilation::compile_java_method()+0x2e4 V [libjvm.so+0x456b70] Compilation::compile_method()+0x10c V [libjvm.so+0x456ee8] Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x1a8 V [libjvm.so+0x457a04] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x74 V [libjvm.so+0x5b18ac] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xd18 V [libjvm.so+0x5b231c] CompileBroker::compiler_thread_loop()+0x4fc V [libjvm.so+0xd87020] JavaThread::thread_main_inner()+0x15c V [libjvm.so+0xd8c0ec] Thread::call_run()+0xb8 V [libjvm.so+0xb75dfc] thread_native_entry(Thread*)+0xdc C [libpthread.so.0+0x78b8] start_thread+0x188 I've also asked them to try running with C1 effectively switched off.
16-11-2023
Okay, thanks for checking [~karianna].
03-07-2023
[~thartmann] unfortunately the OP is not able to share the details of that class. I've asked them to run with a debug build but not sure if they'll give us a result there. The only thing they added was that the function was a JDBC call and the underlying driver is postgresql 42.5.4. I also asked them to run without -XX:TieredStopAtLevel=1 and they've reported no crashes so far with that flag removed.
30-06-2023
[~karianna] Could we get 'care/better/demographics/index/indexing/param/DatabaseAwareSearchParameterRetriever' (.class file is fine) from the submitter? And as usual, other things to try would be: - Run with a more recent JDK version - Run with a debug VM build
26-06-2023
ILW = Same as JDK-8296924 = P3
26-06-2023
Looks like JDK-8296924 but that should be fixed in 17.0.7.
26-06-2023