Bug ID: JDK-8345225 AARCH64: VM crashes with -NearCpool +UseShenandoahGC options

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 25
25 b21Fixed

The -XX:-NearCpool -XX:+UseShenandoahGC JVM run gives an immediate crash on aarch64 (and riscv):

$ ~/jdk-21/bin/java -XX:-NearCpool -XX:+UseShenandoahGC
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000ffff6fd4b4c4, pid=508304, tid=508305
#
# JRE version: OpenJDK Runtime Environment (21.0+37) (build 21+37-LTS)
# Java VM: OpenJDK 64-Bit Server VM (21+37-LTS, mixed mode, tiered, compressed oops, compressed class ptrs, shenandoah gc, linux-aarch64)
# Problematic frame:
# j  java.lang.module.ModuleDescriptor.<init>(Ljava/lang/String;Ljava/lang/module/ModuleDescriptor$Version;Ljava/util/Set;Ljava/util/Set;Ljava/util/Set;Ljava/util/Set;Ljava/util/Set;Ljava/util/Set;Ljava/util/Set;Ljava/lang/String;IZ)V+29 java.base
#
# Core dump will be written. Default location: Core dumps may be processed with "/bin/false" (or dumping to /home/bellsoft/boris/jdk-bulasevich/core.508304)
#

Changeset: 7cf190fb Branch: master Author: Boris Ulasevich <bulasevich@openjdk.org> Date: 2025-04-29 01:50:23 +0000 URL: https://git.openjdk.org/jdk/commit/7cf190fbb02e950eb3b5461be139d09add3f6a7d
29-04-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/24883 Date: 2025-04-25 18:07:22 +0000
25-04-2025
https://github.com/openjdk/jdk/pull/22448
28-11-2024
Is the NearCpool JVM option truly necessary? How is it used? Although NearCpool is described as being related to the constant pool, it is actually applied in loading nmethod.oops() rather than for constant pool loading.
28-11-2024
To fix the problem - MacroAssembler::adrp should use oop_Relocation from movoop (call stack: MacroAssembler::movoop -> MacroAssembler::ldr_constant -> MacroAssembler::adrp -> code_section::relocate) - Relocation::pd_set_data_value should know about adrp+ldr sequence diff --git a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp index 48fb3c2b071..bfec7ef6301 100644 --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp @@ -1420,7 +1420,7 @@ class MacroAssembler: public Assembler { ldr(dest, const_addr); } else { uint64_t offset; - adrp(dest, InternalAddress(const_addr.target()), offset); + adrp(dest, const_addr, offset); ldr(dest, Address(dest, offset)); } } diff --git a/src/hotspot/cpu/aarch64/relocInfo_aarch64.cpp b/src/hotspot/cpu/aarch64/relocInfo_aarch64.cpp index c4c8648d552..41d61ee8626 100644 --- a/src/hotspot/cpu/aarch64/relocInfo_aarch64.cpp +++ b/src/hotspot/cpu/aarch64/relocInfo_aarch64.cpp @@ -42,7 +42,7 @@ void Relocation::pd_set_data_value(address x, bool verify_only) { case relocInfo::oop_type: { oop_Relocation reloc = (oop_Relocation )this; - if (NativeInstruction::is_ldr_literal_at(addr())) { + if (NativeInstruction::is_ldr_literal_at(addr()) \|\| NativeInstruction::is_adrp_at(addr())) { address constptr = (address)code()->oop_addr_at(reloc->oop_index()); bytes = MacroAssembler::pd_patch_instruction_size(addr(), constptr); assert((address)constptr == x, "error in oop relocation");
28-11-2024