JDK-8373092 : AArch64: runtime/cds/appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java#aot segfaults in C2 compiled code with ZGC and CompactObjectHeaders
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 26
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • CPU: aarch64
  • Submitted: 2025-12-04
  • Updated: 2025-12-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 26
26Unresolved
Related Reports
Causes :  
JDK-8371643 - Remove ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch
Description
Note: Title should be updated once the root cause is known

The test

    runtime/cds/appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java#aot
	
intermittnetly segfaults in C2 compiled code when additionally run with

    -XX:+UseZGC -XX:+UseCompactObjectHeaders

on linux-aarch64 and linux-aarch64-debug (could not trigger on linux-x64). It starts to show up after JDK-8371643.

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000ffff93ec4678, pid=3310476, tid=3310479
#
# JRE version: Java(TM) SE Runtime Environment (26.0+27) (build 26-ea+27-2662)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (26-ea+27-2662, mixed mode, sharing, tiered, compact obj headers, z gc, linux-aarch64)
# Problematic frame:
# J 1303 c2 java.lang.invoke.LambdaFormEditor.getInCache(Ljava/lang/invoke/LambdaFormEditor$TransformKey;)Ljava/lang/invoke/LambdaForm; java.base@26-ea (165 bytes) @ 0x0000ffff93ec4678 [0x0000ffff93ec4340+0x0000000000000338]
...........
Command Line: -XX:MaxRAMPercentage=6.25 -Dtest.boot.jdk=/opt/mach5/mesos/work_dir/jib-master/install/jdk/25/37/bundles/linux-aarch64/jdk-25_linux-aarch64_bin.tar.gz/jdk-25 -Djava.io.tmpdir=/opt/mach5/mesos/work_dir/slaves/da1065b5-7b94-4f0d-85e9-a3a252b9a32e-S11684/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/6f5a62ae-0e93-424d-b47b-37fb2d854894/runs/4b32f232-6395-4e83-a5b1-a5ab90ffde2b/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_runtime/tmp -XX:+UseZGC -XX:+UseCompactObjectHeaders -Xlog:class+load,cds=debug -Xlog:arguments,aot,cds:file=MethodHandlesSpreadArgumentsTest.production.log::filesize=0 -XX:AOTMode=on -XX:AOTCache=MethodHandlesSpreadArgumentsTest.aot TestMHApp test.java.lang.invoke.MethodHandlesSpreadArgumentsTest
..........
Current thread (0x0000ffffa40caed0):  JavaThread "main"             [_thread_in_Java, id=3310479, stack(0x0000ffffaaf0f000,0x0000ffffab10d000) (2040K)]

Stack: [0x0000ffffaaf0f000,0x0000ffffab10d000],  sp=0x0000ffffab10aa20,  free space=2030k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
J 1303 c2 java.lang.invoke.LambdaFormEditor.getInCache(Ljava/lang/invoke/LambdaFormEditor$TransformKey;)Ljava/lang/invoke/LambdaForm; java.base@26-ea (165 bytes) @ 0x0000ffff93ec4678 [0x0000ffff93ec4340+0x0000000000000338]
J 886 c1 java.lang.invoke.LambdaFormEditor.spreadArgumentsForm(ILjava/lang/Class;I)Ljava/lang/invoke/LambdaForm; java.base@26-ea (363 bytes) @ 0x0000ffff8c3ec804 [0x0000ffff8c3ec640+0x00000000000001c4]
J 1532 c2 java.lang.invoke.MethodHandle.asSpreader(ILjava/lang/Class;I)Ljava/lang/invoke/MethodHandle; java.base@26-ea (68 bytes) @ 0x0000ffff93f3953c [0x0000ffff93f392c0+0x000000000000027c]
J 1010 c1 test.java.lang.invoke.MethodHandlesSpreadArgumentsTest.testSpreadArguments(Ljava/lang/Class;Ljava/lang/Class;II)V (274 bytes) @ 0x0000ffff8c4489d4 [0x0000ffff8c448540+0x0000000000000494]
j  test.java.lang.invoke.MethodHandlesSpreadArgumentsTest.testSpreadArguments0()V+186
j  test.java.lang.invoke.MethodHandlesSpreadArgumentsTest$$Lambda+0x800000025.run()V+4
j  test.java.lang.invoke.lib.CodeCacheOverflowProcessor$$Lambda+0x80000002a.run()V+4
j  jdk.test.lib.Utils.filterException(Ljdk/test/lib/Utils$ThrowingRunnable;Ljava/util/function/Function;)Ljava/lang/Throwable;+1
j  test.java.lang.invoke.lib.CodeCacheOverflowProcessor.runMHTest(Ljdk/test/lib/Utils$ThrowingRunnable;)Ljava/lang/Throwable;+16
j  test.java.lang.invoke.MethodHandlesSpreadArgumentsTest.testSpreadArguments()V+6
j  java.lang.invoke.LambdaForm$DMH+0x800000024.invokeVirtual(Ljava/lang/Object;Ljava/lang/Object;)V+10 java.base@26-ea
j  java.lang.invoke.LambdaForm$MH+0x000007fe01041000.invoke(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+31 java.base@26-ea
j  java.lang.invoke.Invokers$Holder.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+19 java.base@26-ea
j  jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+41 java.base@26-ea
j  jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+23 java.base@26-ea
j  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+102 java.base@26-ea
j  TestMHApp.main([Ljava/lang/String;)V+194
v  ~StubRoutines::Stub Generator call_stub_stub 0x0000ffff9388e444
V  [libjvm.so+0x8856a4]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x238  (javaCalls.cpp:416)
V  [libjvm.so+0x93dcd8]  jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) [clone .constprop.1]+0x238  (jni.cpp:881)
V  [libjvm.so+0x93ff64]  jni_CallStaticVoidMethod+0xe4  (jni.cpp:1710)
C  [libjli.so+0x3c60]  invokeStaticMainWithArgs+0x58  (java.c:392)
C  [libjli.so+0x4cb0]  JavaMain+0xe30  (java.c:640)
C  [libjli.so+0x7d2c]  ThreadJavaMain+0xc  (java_md.c:646)
C  [libpthread.so.0+0x7950]  start_thread+0x190

siginfo: si_signo: 11 (SIGSEGV), si_code: 2 (SEGV_ACCERR), si_addr: 0x000004000c600000
Comments
Some key info from the hs_err file: ``` # SIGSEGV (0xb) at pc=0x0000ffff93ec4678, pid=3310476, tid=3310479 siginfo: si_signo: 11 (SIGSEGV), si_code: 2 (SEGV_ACCERR), si_addr: 0x000004000c600000 R2=0x000004000c5ffff8 0x0000ffff93ec4678: 49 8C 40 F8 ldr x9, [x2, #8]! <-- the faulting instruction after decoding 40000000000-4000c600000 rw-s 00000000 00:01 54269 /memfd:java_heap (deleted) 4000c600000-407c2000000 ---p 00000000 00:00 0 ``` The faulting instruction is trying to de-reference (X2(R2) + 8), which is just beyond the java_heap. I didn't find any prefetching instructions nearby, so I suspect removing tlab-reserve (JDK-8371643) happens to "expose" the underlying issue. I will backout JDK-8371643 until the underlying issue is resolved.
05-12-2025
Indeed, a backout seems to be the best/safest option, unless the fix is straight forward and low risk.
05-12-2025
Maybe a backout of JDK-8371643 is the best solution for now?
05-12-2025
ILW = Crash in C2 compiled code, intermittent with single test and on AArch64 only, either use different GC or disable COH = HLM = P3
05-12-2025
I could trace it back to JDK-8371643, [~ayang] can you have a look?
05-12-2025