JDK-8252853 : AArch64: gc/shenandoah/TestVerifyJCStress.java fails intermittently with C1
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 8-shenandoah,11.0.9,15,16
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: aarch64
  • Submitted: 2020-09-07
  • Updated: 2024-11-22
  • Resolved: 2020-09-08
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 11 JDK 16
11.0.13Fixed 16 b15Fixed
Related Reports
Relates :  
JDK-8241765 - Shenandoah: AARCH64 need to save/restore call clobbered registers before calling keepalive barrier
Description
The #2 configuration (-XX:ShenandoahGCMode=iu) fails occasionally on some AArch64 machines when run with  -XX:TieredStopAtLevel=1. 

Looks like ShenandoahBarrierSetAssembler::storeval_barrier() needs to save more registers (all the call clobbered ones).

java.util.concurrent.ExecutionException: java.lang.NullPointerException: Cannot assign field "prev" because "node" is null
    at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
    at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
    at TestVerifyJCStress.main(TestVerifyJCStress.java:109)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:564)
    at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
    at java.base/java.lang.Thread.run(Thread.java:832)
Caused by: java.lang.NullPointerException: Cannot assign field "prev" because "node" is null
    at java.base/java.util.concurrent.locks.StampedLock.acquireWrite(StampedLock.java:1221)
    at java.base/java.util.concurrent.locks.StampedLock.writeLockInterruptibly(StampedLock.java:536)
    at TestVerifyJCStress$Test.WLI_Us(TestVerifyJCStress.java:133)
    at TestVerifyJCStress.lambda$main$2(TestVerifyJCStress.java:104)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
    ... 1 moreJavaTest Message: Test threw exception: java.util.concurrent.ExecutionException: java.lang.NullPointerException: Cannot assign field "prev" because "node" is null
Comments
Fix Request (11u) This fixes the Shenandoah bug on AArch64. Patch does not apply cleanly due to different context. 11u RFR is acked by rkennke and zgu.
19-08-2021
Changeset: 4fb1980f Author: Nick Gasson <ngasson@openjdk.org> Date: 2020-09-08 10:17:25 +0000 URL: https://git.openjdk.java.net/jdk/commit/4fb1980f
08-09-2020
I wonder if x86 has a similar issue: in storeval_barrier_impl() it saves all the integer registers (via pusha) plus xmm0 around satb_write_barrier_pre(). Does it need to save the other xmm registers as these could potentially be clobbered by the VM call in the slow path? This can be expanded directly from C1 which might be using other floating registers.
08-09-2020
Seems similar to JDK-8241765.
08-09-2020
Can also reproduce using jcstress with -jvmArgs 'XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=iu -XX:TieredStopAtLevel=1'
07-09-2020