JDK-8285923 : [REDO] JDK-8285802 AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,17,18,19
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,os_x
  • CPU: aarch64
  • Submitted: 2022-04-29
  • Updated: 2022-06-24
  • Resolved: 2022-05-09
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 19
17.0.5-oracleFixed 19 b22Fixed
Related Reports
Relates :  
JDK-8287091 - aarch64 : guarantee(val < (1ULL << nbits)) failed: Field too big for insn
Relates :  
JDK-8285802 - AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities
Sub Tasks
JDK-8285945 :  
[BACKOUT] JDK-8285802 AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities - Resolved
Description
The following tests are failing in the JDK19 CI in Tier1:

tools/doclint/tool/StatsTest.java
jdk/javadoc/tool/8224612/OptionsTest.java
jdk/javadoc/doclet/testDocletExample/TestDocletExample.java

Here's hs_err_pid snippets from the OptionsTest.java failure:

#  Internal Error (assembler_aarch64.hpp:251), pid=3232143, tid=3232158
#  guarantee(val < (1ULL << nbits)) failed: Field too big for insn
#
# JRE version: Java(TM) SE Runtime Environment (19.0+21) (build 19-ea+21-1423)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (19-ea+21-1423, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# V  [libjvm.so+0xac4848]  Assembler::movz(RegisterImpl const*, unsigned int, unsigned int)+0x138

<snip>

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

Current thread (0x0000fffde830d5f0):  JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=3232158, stack(0x0000fffdbeed0000,0x0000fffdbf0d0000)]


Current CompileTask:
C2:   1880 2623       4       javadoc.tester.HtmlParser::htmlAttrs (236 bytes)

Stack: [0x0000fffdbeed0000,0x0000fffdbf0d0000],  sp=0x0000fffdbf0cb2c0,  free space=2028k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xac4848]  Assembler::movz(RegisterImpl const*, unsigned int, unsigned int)+0x138
V  [libjvm.so+0xaac198]  MacroAssembler::mov_immediate64(RegisterImpl const*, unsigned long)+0x498
V  [libjvm.so+0xaaf818]  MacroAssembler::wrap_adds_subs_imm_insn(RegisterImpl const*, RegisterImpl const*, unsigned long, void (MacroAssembler::*)(RegisterImpl const*, RegisterImpl const*, unsigned int), void (MacroAssembler::*)(RegisterImpl const*, RegisterImpl const*, RegisterImpl const*, Assembler::shift_kind, unsigned int))+0x94
V  [libjvm.so+0x336fe0]  overflowAddI_reg_immNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0xbc
V  [libjvm.so+0xb9f4f4]  PhaseOutput::scratch_emit_size(Node const*)+0x1a4
V  [libjvm.so+0xb9bdb4]  PhaseOutput::shorten_branches(unsigned int*)+0x234
V  [libjvm.so+0xba2b50]  PhaseOutput::Output()+0x480
V  [libjvm.so+0x5bf7e4]  Compile::Code_Gen()+0x460
V  [libjvm.so+0x5c2c5c]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0xe7c
V  [libjvm.so+0x50be8c]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xf8
V  [libjvm.so+0x5ca368]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x758
V  [libjvm.so+0x5cb0c8]  CompileBroker::compiler_thread_loop()+0x468
V  [libjvm.so+0xd030ec]  JavaThread::thread_main_inner()+0xbc
V  [libjvm.so+0xd08b78]  Thread::call_run()+0xb8
V  [libjvm.so+0xb8c5cc]  thread_native_entry(Thread*)+0xdc
C  [libpthread.so.0+0x7868]  start_thread+0x188
Comments
Fix request [17u] I backport this for parity with 17.0.5-oracle. I had to do a trivial resolve. I'll integrate after 8287091. SAP nightly testing passed.
24-06-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/501 Date: 2022-06-23 10:37:02 +0000
23-06-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk18u/pull/159 Date: 2022-06-21 07:34:12 +0000
21-06-2022
Changeset: b849efdf Author: Andrew Haley <aph@openjdk.org> Date: 2022-05-09 13:37:15 +0000 URL: https://git.openjdk.java.net/jdk/commit/b849efdf154552903faaddd69cac1fe5f1ddf18a
09-05-2022
Mach5 testing: Mach5 Tier1: - no failures Mach5 Tier2: - 1 unrelated, known failure Mach5 Tier3: - no failures Mach5 Tier4: - no failures Mach5 Tier5: - no failures
07-05-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/8554 Date: 2022-05-05 14:56:38 +0000
05-05-2022
We've been looking with @fferrari into this issue. The problem is caused by the removal of the cast "(int)imm" in MacroAssembler::wrap_adds_subs_imm_insn [0]. After 8285802, we pass a uint64_t imm to Assembler::operand_valid_for_add_sub_immediate [1] which, in turn, will cast it to int64_t imm. There is no sign extension in that cast. Before 8285802, Assembler::operand_valid_for_add_sub_immediate was receiving an int and casting it to int64_t implied a sign extension. To illustrate, let's say that imm is -1. After 8285802, Assembler::operand_valid_for_add_sub_immediate gets a (int64_t)0x00000000FFFFFFFF instead of a (int64_t)0xFFFFFFFFFFFFFFFF. What was a small negative before is now a large positive, and it's likely that Assembler::operand_valid_for_add_sub_immediate is now returning false instead of true. Thus, execution reaches this point [2]. Then it calls mov [3] and mov_immediate_64 [4]. It then calls movz [5]. For movz, imm is an unsigned int again. It then calls f [6] asking to encode 0xFFFFFFFF between bits 5 and 20, which is not possible, and we finally trigger the assertion here [7]. If we look from MacroAssembler::wrap_adds_subs_imm_insn backwards, the call on the test that failed comes from overflowAddI_reg_immNode::emit (auto-generated, ad_aarch64.cpp). This function called cmnw [8], which then called addsw [9] [10]. It's worth noting how the pass through cmnw implied that imm was casted to unsigned int. Thus, after 8285802 imm was forced to unsigned int, then to uint64_t and then to int64_t. Whereas before 8285802, the cast path for imm was unsigned int, to int, to int64_t. As an example, this C++ code reflects the two cast paths and how they throw different results: #include <iostream> #include <string> #include <cstdint> int main() { { // Input unsigned int i = (unsigned int)-1; unsigned int u = (unsigned int)i; int i_tmp = (int)u; std::cout << "i (before 8285802): " << std::hex << (int64_t)i_tmp << std::endl; } { // Input unsigned int i = (unsigned int)-1; uint64_t u = (uint64_t)i; std::cout << "i (after 8285802): " << std::hex << (int64_t)u << std::endl; } } -- [0] - https://github.com/openjdk/jdk/commit/df4d5cf5f53c1451487e6301d31c196fac029f7a#diff-0f4150a9c607ccd590bf256daa800c0276144682a92bc6bdced5e8bc1bb81f3aL2218 [1] - https://github.com/openjdk/jdk/blob/jdk-19%2B20/src/hotspot/cpu/aarch64/assembler_aarch64.cpp#L438 [2] - https://github.com/openjdk/jdk/blob/jdk-19%2B20/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L2223 [3] - https://github.com/openjdk/jdk/blob/jdk-19%2B20/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp#L495 [4] - https://github.com/openjdk/jdk/blob/jdk-19%2B20/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L1390 [5] - https://github.com/openjdk/jdk/blob/jdk-19%2B20/src/hotspot/cpu/aarch64/assembler_aarch64.hpp#L791 [6] - https://github.com/openjdk/jdk/blob/jdk-19%2B20/src/hotspot/cpu/aarch64/assembler_aarch64.hpp#L796 [7] - https://github.com/openjdk/jdk/blob/jdk-19%2B20/src/hotspot/cpu/aarch64/assembler_aarch64.hpp#L251 [8] - https://github.com/openjdk/jdk/blob/jdk-19%2B20/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp#L196 [9] - https://github.com/openjdk/jdk/blob/jdk-19%2B20/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp#L1196 [10] - https://github.com/openjdk/jdk/blob/jdk-19%2B20/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp#L1179
02-05-2022
Changed the priority to match JDK-8285802 (P3). Also changed the synopsis to reflect that this bug is now the [REDO] for JDK-8285802
30-04-2022
ILW = crash in tier1 testing; intermittent; no workaround = HMH = P1
29-04-2022
Here's hs_err_pid snippets for the jdk-19+21-1429-tier2 sighting: java/net/httpclient/ResponseBodyBeforeError.java # Internal Error (assembler_aarch64.hpp:251), pid=1906218, tid=1906273 # guarantee(val < (1ULL << nbits)) failed: Field too big for insn # # JRE version: Java(TM) SE Runtime Environment (19.0+21) (build 19-ea+21-1429) # Java VM: Java HotSpot(TM) 64-Bit Server VM (19-ea+21-1429, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) # Problematic frame: # V [libjvm.so+0x39bd00] Instruction_aarch64::f(unsigned int, int, int)+0x80 <snip> --------------- T H R E A D --------------- Current thread (0x0000fffef41f7710): JavaThread "C2 CompilerThread2" daemon [_thread_in_native, id=1906273, stack(0x0000fffef3580000,0x0000fffef3780000)] Current CompileTask: C2: 4866 4423 4 sun.security.ssl.HKDF::<init> (58 bytes) Stack: [0x0000fffef3580000,0x0000fffef3780000], sp=0x0000fffef377b2c0, free space=2028k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x39bd00] Instruction_aarch64::f(unsigned int, int, int)+0x80 V [libjvm.so+0xaabf00] MacroAssembler::mov_immediate64(RegisterImpl const*, unsigned long)+0x200 V [libjvm.so+0xaaf818] MacroAssembler::wrap_adds_subs_imm_insn(RegisterImpl const*, RegisterImpl const*, unsigned long, void (MacroAssembler::*)(RegisterImpl const*, RegisterImpl const*, unsigned int), void (MacroAssembler::*)(RegisterImpl const*, RegisterImpl const*, RegisterImpl const*, Assembler::shift_kind, unsigned int))+0x94 V [libjvm.so+0x336fe0] overflowAddI_reg_immNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0xbc V [libjvm.so+0xb9f4e4] PhaseOutput::scratch_emit_size(Node const*)+0x1a4 V [libjvm.so+0xb9bda4] PhaseOutput::shorten_branches(unsigned int*)+0x234 V [libjvm.so+0xba2b40] PhaseOutput::Output()+0x480 V [libjvm.so+0x5bf7e4] Compile::Code_Gen()+0x460 V [libjvm.so+0x5c2c5c] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0xe7c V [libjvm.so+0x50be8c] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xf8 V [libjvm.so+0x5ca368] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x758 V [libjvm.so+0x5cb0c8] CompileBroker::compiler_thread_loop()+0x468 V [libjvm.so+0xd030cc] JavaThread::thread_main_inner()+0xbc V [libjvm.so+0xd08b58] Thread::call_run()+0xb8 V [libjvm.so+0xb8c5bc] thread_native_entry(Thread*)+0xdc C [libpthread.so.0+0x7868] start_thread+0x188
29-04-2022
The failures have been intermittent in Mach5. We've had 4 Tier1 job sets with failures and 2 Tier1 job sets with no failures. The failing Tier1 job sets are sometimes only linux-aarch64 failures or only macosx-aarch64 failures. I think there was one Tier1 that had failures in both linux-aarch64 and macosx-aarch64 (and not the same tests between them). Weird!
29-04-2022
Never mind, I see you did it. Sorry for the noise.
29-04-2022
OK, sorry. I didn't see that failure in my tests. If this is causing people problems I can simply post a PR to back out the change, and try again some time in the future with a different patch. Should I do that? BTW, it's a public holiday here on Monday.
29-04-2022
We're now seeing JCK tests fail with this assertion failure: On linux-aarch64: api/javax_swing/plaf/metal/MetalFileChooserUI/FilterComboBoxRenderer/Ctor.html api/javax_swing/plaf/basic/BasicLabelUI/protected.html On macosx-aarch64: api/javax_swing/plaf/BorderUIResource/TitledBorderUIResource/TitledBorderUIResourceTests.html api/javax_swing/plaf/basic/BasicFileChooserUI/file.html api/javax_swing/JLabel/AccessibleJLabel/AccessibleContext.html
29-04-2022
[~aph] - Looks like your fix for: JDK-8285802 AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities is causing some Tier1 test failure in jdk/javadoc. Please take a look as soon as possible.
29-04-2022
The first Tier1 build-ID containing these failures includes just one changeset: 2022-04-29 13:01 aph: df4d5c - OpenJDK 8285802 AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities
29-04-2022
The next Tier1 failed jdk/javadoc/doclet tests on macosx-aarch64: jdk/javadoc/doclet/testVersionTag/TestVersionTag.java jdk/javadoc/doclet/testModules/TestModuleServicesLink.java Both of these failed this assertion: # Internal Error (assembler_aarch64.hpp:251), pid=27134, tid=41987 # guarantee(val < (1ULL << nbits)) failed: Field too big for insn jdk/javadoc/doclet/testBadPackageFileInJar/TestBadPackageFileInJar.java failed with this error msg, but no hs_err_pid file: ----------stdout:(8/501)---------- [thread 87143 also had an error] # # Compiler replay data is saved as: # /System/Volumes/Data/mesos/work_dir/slaves/779adf21-f3e5-4e6a-a889-8cc0f9bc6fbb-S42613/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/379f3606-79b2-4f98-9329-9db3b6865b71/runs/c6844c27-375f-4393-ab5b-02653b4fa157/testoutput/test-support/jtreg_open_test_langtools_tier1/scratch/2/replay_pid26193.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
29-04-2022
Here's log file snippets from the StatsTest.java failure: #section:main ----------messages:(6/338)---------- command: main DocLintTester -ref StatsTest.out -stats -Xmsgs:all StatsTest.java reason: User specified action: run main DocLintTester -ref StatsTest.out -stats -Xmsgs:all StatsTest.java Mode: agentvm Agent id: 10 Additional exports to unnamed modules from @modules: jdk.javadoc/jdk.javadoc.internal.doclint elapsed time (seconds): 0.001 ----------configuration:(16/1791)---------- <snip> result: Error. Agent communication error: java.net.SocketException: Broken pipe; check console log for any additional details The artifacts link does not have any hs_err_pid files or core files.
29-04-2022
Here's hs_err_pid snippets from the TestDocletExample.java failure: # Internal Error (assembler_aarch64.hpp:251), pid=3203340, tid=3231246 # guarantee(val < (1ULL << nbits)) failed: Field too big for insn # # JRE version: Java(TM) SE Runtime Environment (19.0+21) (build 19-ea+21-1423) # Java VM: Java HotSpot(TM) 64-Bit Server VM (19-ea+21-1423, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) # Problematic frame: # V [libjvm.so+0xac4848] Assembler::movz(RegisterImpl const*, unsigned int, unsigned int)+0x138 <snip> --------------- T H R E A D --------------- Current thread (0x0000fffcbc75f6c0): JavaThread "C2 CompilerThread1" daemon [_thread_in_native, id=3231246, stack(0x0000fffcc6ae0000,0x0000fffcc6ce0000)] Current CompileTask: C2: 101403 15024 4 javadoc.tester.HtmlParser::htmlAttrs (236 bytes) Stack: [0x0000fffcc6ae0000,0x0000fffcc6ce0000], sp=0x0000fffcc6cdb2c0, free space=2028k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xac4848] Assembler::movz(RegisterImpl const*, unsigned int, unsigned int)+0x138 V [libjvm.so+0xaac198] MacroAssembler::mov_immediate64(RegisterImpl const*, unsigned long)+0x498 V [libjvm.so+0xaaf818] MacroAssembler::wrap_adds_subs_imm_insn(RegisterImpl const*, RegisterImpl const*, unsigned long, void (MacroAssembler::*)(RegisterImpl const*, RegisterImpl const*, unsigned int), void (MacroAssembler::*)(RegisterImpl const*, RegisterImpl const*, RegisterImpl const*, Assembler::shift_kind, unsigned int))+0x94 V [libjvm.so+0x336fe0] overflowAddI_reg_immNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0xbc V [libjvm.so+0xb9f4f4] PhaseOutput::scratch_emit_size(Node const*)+0x1a4 V [libjvm.so+0xb9bdb4] PhaseOutput::shorten_branches(unsigned int*)+0x234 V [libjvm.so+0xba2b50] PhaseOutput::Output()+0x480 V [libjvm.so+0x5bf7e4] Compile::Code_Gen()+0x460 V [libjvm.so+0x5c2c5c] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0xe7c V [libjvm.so+0x50be8c] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xf8 V [libjvm.so+0x5ca368] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x758 V [libjvm.so+0x5cb0c8] CompileBroker::compiler_thread_loop()+0x468 V [libjvm.so+0xd030ec] JavaThread::thread_main_inner()+0xbc V [libjvm.so+0xd08b78] Thread::call_run()+0xb8 V [libjvm.so+0xb8c5cc] thread_native_entry(Thread*)+0xdc C [libpthread.so.0+0x7868] start_thread+0x188
29-04-2022