Bug ID: JDK-8320682 [AArch64] C1 compilation fails with "Field too big for insn"

JDK-8320682 : [AArch64] C1 compilation fails with "Field too big for insn"

Type: Bug
Component: hotspot
Sub-Component: compiler
Affected Version: 17,21,22,23

Priority: P3
Status: Resolved
Resolution: Fixed
OS: linux
CPU: aarch64

Submitted: 2023-11-24
Updated: 2025-04-15
Resolved: 2023-12-14

Versions (Unresolved/Resolved/Fixed)

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.16Fixed	21.0.6Fixed	22Fixed	23 b03Fixed

Related Reports

Relates :	JDK-8310844 - [AArch64] C1 compilation fails because monitor offset in OSR buffer is too large for immediate
Relates :	JDK-8319700 - [AArch64] C2 compilation fails with "Field too big for insn"
Relates :	JDK-8318817 - Could not reserve enough space in CodeHeap 'profiled nmethods' (0K)

Description

### Failure analysis ###
The issue is due to using PC-relative addressing (the aarch64 adr instruction) with an (unusually) large non-nmethod code heap size. Attempting to load the address of a constant that is out of range triggers the assert/guarantee.

### Original report ###
In the tier 6 test run that included the fix for JDK-8319700 we saw the same failure.

Test: compiler/arguments/TestC1Globals.java#id4	

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/mach5/mesos/work_dir/slaves/0db9c48f-6638-40d0-9a4b-bd9cc7533eb8-S10903/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/0724edac-4f9d-4b23-a291-90fd75eb8a31/runs/365cdd81-6ab1-4745-a986-7340646f3a7b/workspace/open/src/hotspot/cpu/aarch64/assembler_aarch64.hpp:265), pid=2092794, tid=2092814
#  guarantee(chk == -1 || chk == 0) failed: Field too big for insn
#
# JRE version: Java(TM) SE Runtime Environment (22.0+26) (fastdebug build 22-ea+26-2029)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-ea+26-2029, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# V  [libjvm.so+0x5b9958]  Assembler::adr(Register, unsigned char*)+0x148
#
Host: AArch64, 8 cores, 30G, Oracle Linux Server release 8.8
Time: Fri Nov 24 01:16:05 2023 UTC elapsed time: 2.811199 seconds (0d 0h 0m 2s)

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

Current thread (0x0000ffff7837e0a0):  JavaThread "C1 CompilerThread0" daemon [_thread_in_native, id=2092814, stack(0x0000ffff23e02000,0x0000ffff24000000) (2040K)]

Current CompileTask:
C1:2811  242    b  3       java.util.HashMap::putMapEntries (170 bytes)

Stack: [0x0000ffff23e02000,0x0000ffff24000000],  sp=0x0000ffff23ffbc00,  free space=2023k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x5b9958]  Assembler::adr(Register, unsigned char*)+0x148  (assembler_aarch64.hpp:265)
V  [libjvm.so+0x698ff8]  LIR_Assembler::const2reg(LIR_Opr, LIR_Opr, LIR_PatchCode, CodeEmitInfo*)+0x3b8  (c1_LIRAssembler_aarch64.cpp:588)
V  [libjvm.so+0x68c194]  LIR_Assembler::move_op(LIR_Opr, LIR_Opr, BasicType, LIR_PatchCode, CodeEmitInfo*, bool, bool)+0x310  (c1_LIRAssembler.cpp:816)
V  [libjvm.so+0x68da68]  LIR_Assembler::emit_lir_list(LIR_List*)+0xf8  (c1_LIRAssembler.cpp:304)
V  [libjvm.so+0x68e6f0]  LIR_Assembler::emit_code(BlockList*)+0x270  (c1_LIRAssembler.cpp:269)
V  [libjvm.so+0x63720c]  Compilation::emit_code_body()+0x14c  (c1_Compilation.cpp:358)
V  [libjvm.so+0x6377d0]  Compilation::compile_java_method()+0x390  (c1_Compilation.cpp:421)
V  [libjvm.so+0x638060]  Compilation::compile_method()+0x1fc  (c1_Compilation.cpp:482)
V  [libjvm.so+0x6386ec]  Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x25c  (c1_Compilation.cpp:612)
V  [libjvm.so+0x63a464]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xa4  (c1_Compiler.cpp:258)
V  [libjvm.so+0x8f2b44]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x7e0  (compileBroker.cpp:2305)
V  [libjvm.so+0x8f372c]  CompileBroker::compiler_thread_loop()+0x598  (compileBroker.cpp:1964)
V  [libjvm.so+0xd6b248]  JavaThread::thread_main_inner()+0xe4  (javaThread.cpp:720)
V  [libjvm.so+0x159a1e0]  Thread::call_run()+0xac  (thread.cpp:220)
V  [libjvm.so+0x130d4cc]  thread_native_entry(Thread*)+0x12c  (os_linux.cpp:787)
C  [libpthread.so.0+0x7928]  start_thread+0x188

Comments

[jdk17u-fix-request] Approval Request from Boris The issue is applicable to jdk17u as well. The change is safe and well tested.
14-04-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk17u-dev/pull/3432 Date: 2025-04-03 13:53:32 +0000
03-04-2025
[jdk21u-fix-request] Approval Request from Boris The backport fixes C1 internal error caused by adr limit being broken by too large NMethodSizeLimit option value. The change is safe and simple. Let us do it.
01-10-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk21u-dev/pull/956 Date: 2024-09-05 17:24:26 +0000
05-09-2024
The fix for this bug is integrated in jdk-22+29-2277.
15-12-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk22/pull/15 Date: 2023-12-15 10:55:48 +0000
15-12-2023
The fix for this bug is integrated in jdk-23+2-76.
14-12-2023
Changeset: 69014cd5 Author: Daniel Lundén <daniel.lunden@oracle.com> Committer: Roberto Castañeda Lozano <rcastanedalo@openjdk.org> Date: 2023-12-14 13:09:39 +0000 URL: https://git.openjdk.org/jdk/commit/69014cd55b59a0a63f4918fad575a6887640573e
14-12-2023
Here's a log file snippet for the jdk-23+2-54-tier6 sighting: compiler/arguments/TestC1Globals.java#id4 #section:main ----------messages:(6/391)---------- command: main -XX:NMethodSizeLimit=224001703 -XX:+UseTransparentHugePages compiler.arguments.TestC1Globals reason: User specified action: run main/othervm -XX:NMethodSizeLimit=224001703 -XX:+UseTransparentHugePages compiler.arguments.TestC1Globals started: Wed Dec 13 14:35:08 UTC 2023 Mode: othervm [/othervm specified] finished: Wed Dec 13 14:35:15 UTC 2023 elapsed time (seconds): 6.736 ----------configuration:(0/0)---------- ----------System.out:(22/2126)---------- # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/opt/mach5/mesos/work_dir/slaves/0db9c48f-6638-40d0-9a4b-bd9cc7533eb8-S9728/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/2011e6f1-c154-4e7b-a106-62868f9fed7f/runs/c20fe407-979a-4d94-830f-d1ed2bcd09bd/workspace/open/src/hotspot/cpu/aarch64/assembler_aarch64.hpp:265), pid=2089753, tid=2089770 # guarantee(chk == -1 \|\| chk == 0) failed: Field too big for insn # # JRE version: Java(TM) SE Runtime Environment (23.0+2) (fastdebug build 23-ea+2-54) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 23-ea+2-54, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) # Problematic frame: # V [libjvm.so+0x5bbfd8] Assembler::adr(Register, unsigned char)+0x148 # # Core dump will be written. Default location: Core dumps may be processed with "/opt/core.sh %p" (or dumping to /opt/mach5/mesos/work_dir/slaves/0db9c48f-6638-40d0-9a4b-bd9cc7533eb8-S10011/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/250aa595-6773-4cc1-81de-08967216407c/runs/7ddb3529-b2bb-4157-968a-5a9e39c4b8ba/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_not_fast_compiler/scratch/1/core.2089753) # # An error report file with more information is saved as: # /opt/mach5/mesos/work_dir/slaves/0db9c48f-6638-40d0-9a4b-bd9cc7533eb8-S10011/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/250aa595-6773-4cc1-81de-08967216407c/runs/7ddb3529-b2bb-4157-968a-5a9e39c4b8ba/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_not_fast_compiler/scratch/1/hs_err_pid2089753.log # # Compiler replay data is saved as: # /opt/mach5/mesos/work_dir/slaves/0db9c48f-6638-40d0-9a4b-bd9cc7533eb8-S10011/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/250aa595-6773-4cc1-81de-08967216407c/runs/7ddb3529-b2bb-4157-968a-5a9e39c4b8ba/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_not_fast_compiler/scratch/1/replay_pid2089753.log # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # ----------System.err:(0/0)---------- ----------rerun:(44/6451)---------- <snip> result: Failed. Unexpected exit from test [exit code: 134] And here's the crashing thread's stack: --------------- T H R E A D --------------- Current thread (0x0000ffffa8380a10): JavaThread "C1 CompilerThread0" daemon [_thread_in_native, id=2089770, stack(0x0000ffff8c007000,0x0000ffff8c205000) (2040K)] Current CompileTask: C1:1620 244 b 3 java.util.HashMap::putMapEntries (170 bytes) Stack: [0x0000ffff8c007000,0x0000ffff8c205000], sp=0x0000ffff8c200c00, free space=2023k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x5bbfd8] Assembler::adr(Register, unsigned char)+0x148 (assembler_aarch64.hpp:265) V [libjvm.so+0x69b388] LIR_Assembler::const2reg(LIR_Opr, LIR_Opr, LIR_PatchCode, CodeEmitInfo)+0x3b8 (c1_LIRAssembler_aarch64.cpp:588) V [libjvm.so+0x68f0b4] LIR_Assembler::move_op(LIR_Opr, LIR_Opr, BasicType, LIR_PatchCode, CodeEmitInfo, bool, bool)+0x310 (c1_LIRAssembler.cpp:816) V [libjvm.so+0x690988] LIR_Assembler::emit_lir_list(LIR_List)+0xf8 (c1_LIRAssembler.cpp:304) V [libjvm.so+0x691610] LIR_Assembler::emit_code(BlockList)+0x270 (c1_LIRAssembler.cpp:269) V [libjvm.so+0x63986c] Compilation::emit_code_body()+0x14c (c1_Compilation.cpp:358) V [libjvm.so+0x639e30] Compilation::compile_java_method()+0x390 (c1_Compilation.cpp:421) V [libjvm.so+0x63a6c0] Compilation::compile_method()+0x1fc (c1_Compilation.cpp:482) V [libjvm.so+0x63ad4c] Compilation::Compilation(AbstractCompiler, ciEnv, ciMethod, int, BufferBlob, bool, DirectiveSet)+0x25c (c1_Compilation.cpp:612) V [libjvm.so+0x63cac4] Compiler::compile_method(ciEnv, ciMethod, int, bool, DirectiveSet)+0xa4 (c1_Compiler.cpp:257) V [libjvm.so+0x8f3714] CompileBroker::invoke_compiler_on_method(CompileTask)+0x7e0 (compileBroker.cpp:2299) V [libjvm.so+0x8f42fc] CompileBroker::compiler_thread_loop()+0x598 (compileBroker.cpp:1958) V [libjvm.so+0xd746b8] JavaThread::thread_main_inner()+0xe4 (javaThread.cpp:720) V [libjvm.so+0x15abd80] Thread::call_run()+0xac (thread.cpp:220) V [libjvm.so+0x131e9cc] thread_native_entry(Thread*)+0x12c (os_linux.cpp:789) C [libpthread.so.0+0x7928] start_thread+0x188
13-12-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/16951 Date: 2023-12-04 14:19:10 +0000
04-12-2023
Can also be triggered like this: $ java -XX:CompileOnly=java.util.HashMap::putMapEntries -Xcomp -XX:NMethodSizeLimit=224001703 --version
30-11-2023
I could trace it back to JDK-8318817. Before that, the VM just exits with: Error occurred during initialization of VM Could not reserve enough space in CodeHeap 'profiled nmethods' (0K) The problem might be that C1 directly takes NMethodSizeLimit as code buffer size: static uint desired_max_code_buffer_size() { return (uint)NMethodSizeLimit; // default 64K } Which could then be too large to use an immediate for the assembly instruction. But that's just a guess. A workaround could be to use a smaller NMethodSizeLimit. A quick binary search with the replay file showed that NMethodSizeLimit values larger than 1049455 trigger the assertion. [~dlunden] can you have a look?
27-11-2023
Can be reproduced with the attached replay file replay.log: $ java -XX:NMethodSizeLimit=224001703 -XX:+ReplayCompiles -XX:+ReplayIgnoreInitErrors -XX:ReplayDataFile=replay.log
27-11-2023
Fails intermittently (6 out of 50 runs of TestC1Globals.java, run with -Xcomp -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation)
27-11-2023
[~chagedorn] It's definitely unrelated to JDK-8319700.
27-11-2023
[~aboldtch] Since you fixed JDK-8319700, can you also have a look at that even though it seems unrelated?
24-11-2023
ILW = Same as JDK-8310844 = P3
24-11-2023
I don't think this is related to or caused by JDK-8319700 because that fix is ZGC specific. This one happens with G1. It might be related to JDK-8310844.
24-11-2023