JDK-8350258 : AArch64: Client build fails after JDK-8347917
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 25
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: aarch64
  • Submitted: 2025-02-18
  • Updated: 2025-03-07
  • Resolved: 2025-02-21
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 b12Fixed
Related Reports
Causes :  
Description
configure:

--with-debug-level=release  --disable-precompiled-headers --with-jvm-variants=client


error msg:

# A fatal error has been detected by the Java Runtime Environment:              
                                                                             
#  Internal Error (oopMap.inline.hpp:122), pid=4012461, tid=4012473             
#  guarantee(loc != nullptr) failed: missing saved register                        5 #                                                                               
# JRE version: OpenJDK Runtime Environment (25.0) (build 25-internal-git-7d11418c820)
# Java VM: OpenJDK 64-Bit Client VM (25-internal-git-7d11418c820, mixed mode, emulated-client, compressed oops, compressed class ptrs, serial gc, linux-aarch64)
# Problematic frame:                                                            
# V  [libjvm.so+0x673364]  void OopMapDo<OopClosure, DerivedOopClosure, SkipNullValue>::iterate_oops_do<RegisterMap>(frame const*, RegisterMap const*, ImmutableOopMap const*)+0x314


backtrace:

Stack: [0x0000f74d1c690000,0x0000f74d1c890000],  sp=0x0000f74d1c88d330,  free space=2036k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) 
V  [libjvm.so+0x673364]  void OopMapDo<OopClosure, DerivedOopClosure, SkipNullValue>::iterate_oops_do<RegisterMap>(frame const*, RegisterMap const*, ImmutableOopMap const*)+0x314  (oopMap.inline.hpp:122)
V  [libjvm.so+0x672e6c]  ImmutableOopMap::oops_do(frame const*, RegisterMap const*, OopClosure*, DerivedPointerIterationMode) const+0x6c  (oopMap.inline.hpp:155)
V  [libjvm.so+0x312144]  frame::oops_do_internal(OopClosure*, NMethodClosure*, DerivedOopClosure*, DerivedPointerIterationMode, RegisterMap const*, bool) const+0x1d4  (frame.cpp:983)
V  [libjvm.so+0x45c108]  JavaThread::oops_do_frames(OopClosure*, NMethodClosure*) [clone .part.0]+0xc8  (frame.hpp:483)
V  [libjvm.so+0x8cde4c]  Thread::oops_do(OopClosure*, NMethodClosure*)+0xbc  (thread.cpp:449)
V  [libjvm.so+0x8d9ef4]  Threads::oops_do(OopClosure*, NMethodClosure*)+0x64  (threads.cpp:1143)
V  [libjvm.so+0x701f78]  SerialHeap::process_roots(SerialHeap::ScanningOption, OopClosure*, CLDClosure*, CLDClosure*, NMethodToOopClosure*)+0x58  (serialHeap.cpp:586)
V  [libjvm.so+0x2bc784]  DefNewGeneration::collect(bool)+0x2e4  (defNewGeneration.cpp:628)
V  [libjvm.so+0x703470]  SerialHeap::do_young_collection(bool) [clone .part.0]+0x27c  (serialHeap.cpp:468)
V  [libjvm.so+0x703c80]  SerialHeap::collect_at_safepoint(bool)+0x80  (serialHeap.cpp:444)
V  [libjvm.so+0x703d68]  SerialHeap::satisfy_failed_allocation(unsigned long, bool)+0xb8  (serialHeap.cpp:532)
V  [libjvm.so+0x708568]  VM_SerialCollectForAllocation::doit()+0x38  (serialVMOperations.cpp:31)
V  [libjvm.so+0x91eff8]  VM_Operation::evaluate()+0xf8  (vmOperations.cpp:74)   
V  [libjvm.so+0x922044]  VMThread::evaluate_operation(VM_Operation*)+0x134  (vmThread.cpp:282)
V  [libjvm.so+0x922d10]  VMThread::inner_execute(VM_Operation*)+0x310  (vmThread.cpp:426)
V  [libjvm.so+0x92304c]  VMThread::run()+0xac  (vmThread.cpp:492)               
V  [libjvm.so+0x8ce338]  Thread::call_run()+0xa8  (thread.cpp:231)              
V  [libjvm.so+0x687c88]  thread_native_entry(Thread*)+0xd8  (os_linux.cpp:877)  
C  [libc.so.6+0x8595c]                                                          
JavaThread 0x0000f74d1802aaf0 (nid = 4012465) was being processed               
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)                  
j  java.nio.file.Files.read(Ljava/io/InputStream;I)[B+3 java.base               
J 930 c1 java.nio.file.Files.readAllBytes(Ljava/nio/file/Path;)[B java.base (127 bytes) @ 0x0000f74d1cf0ed84 [0x0000f74d1cf0eae0+0x00000000000002a4]
j  jdk.internal.module.ModuleReferences$ExplodedModuleReader.read(Ljava/lang/String;)Ljava/util/Optional;+18 java.base
j  jdk.internal.loader.BuiltinClassLoader.defineClass(Ljava/lang/String;Ljdk/internal/loader/BuiltinClassLoader$LoadedModule;)Ljava/lang/Class;+79 java.base
J 746 c1 jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(Ljava/lang/String;Z)Ljava/lang/Class; java.base (143 bytes) @ 0x0000f74d1cee69d0 [0x0000f74d1cee6720+0x00000000000002b0]
J 776 c1 jdk.internal.loader.BuiltinClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class; java.base (22 bytes) @ 0x0000f74d1ceec894 [0x0000f74d1ceec820+0x0000000000000074]
J 775 c1 java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class; java.base (7 bytes) @ 0x0000f74d1ceec650 [0x0000f74d1ceec5e0+0x0000000000000070]
v  ~StubRoutines::call_stub 0x0000f74d1cd40118                                  
j  com.sun.tools.javac.processing.JavacProcessingEnvironment.<init>(Lcom/sun/tools/javac/util/Context;)V+12 jdk.compiler
j  com.sun.tools.javac.processing.JavacProcessingEnvironment.instance(Lcom/sun/tools/javac/util/Context;)Lcom/sun/tools/javac/processing/JavacProcessingEnvironment;+19 jdk.compiler
j  com.sun.tools.javac.api.BasicJavacTask.initPlugins(Ljava/util/Set;)V+148 jdk.compiler
j  com.sun.tools.javac.main.Main.compile([Ljava/lang/String;Lcom/sun/tools/javac/util/Context;)Lcom/sun/tools/javac/main/Main$Result;+475 jdk.compiler
j  com.sun.tools.javac.main.Main.compile([Ljava/lang/String;)Lcom/sun/tools/javac/main/Main$Result;+15 jdk.compiler
j  com.sun.tools.javac.Main.compile([Ljava/lang/String;)I+12 jdk.compiler       
j  com.sun.tools.javac.Main.main([Ljava/lang/String;)V+1 jdk.compiler           
v  ~StubRoutines::call_stub 0x0000f74d1cd40118    

Comments
Changeset: 25322aae Branch: master Author: Dmitry Chuyko <dchuyko@openjdk.org> Date: 2025-02-21 21:43:54 +0000 URL: https://git.openjdk.org/jdk/commit/25322aae8e224680db376098d2e45f26cf3334a0
21-02-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/23682 Date: 2025-02-18 22:42:18 +0000
18-02-2025

What seems to be missing is a set known location for rfp, which can to be handled by frame::update_map_with_saved_link(RegisterMapT* map, intptr_t** link_addr): ``` // The interpreter and compiler(s) always save FP in a known // location on entry. C2-compiled code uses FP as an allocatable // callee-saved register. We must record where that location is so // that if FP was live on callout from c2 we can find the saved copy. ```
18-02-2025

The crash is mostly reproducible. Adding '-J-XX:+PreserveFramePointer' to javac invocation prevents the crash. > We may update to treat rfp as not caller-saved reg only if PreserveFramePointer is on. rfp is a bit special as it is saved/restored anyway when the frame is constructed.
18-02-2025

Sure, I'll take a look into this.
18-02-2025

I'm tentatively assigning this to [~dchuyko] to have a look as suggested by [~haosun] - feel free to reassign.
18-02-2025

ILW = aarch64 client build failure, always but only with client build, no workaround = MMH = P3
18-02-2025

I didn't fully understand the root cause. here is just my guess: Currently rfp is not treated as caller-saved reg no matter whether PreserveFramePointer is on or off. I suspect it might be the root cause. We may update to treat rfp as not caller-saved reg only if PreserveFramePointer is on. I was wondering if [~dchuyko] could help take a look at this issue? Thanks.
18-02-2025