In last (at least) half and year, we are seeing jcstress crashes with jdk8 && jfr enabled && aarch64 runs (all other arches, or without jfr are ok).
With last rampdowm it got quite a peak. So maybe it got worse or we have just been "more lucky" (in scope of jcstress).

great test which to run in loop is org.openjdk.jcstress.tests.memeffects.basic.atomicupdaters.AtomicLongFieldUpdater.atomic_getAndSet_set_short
I'm adding to the run: -XX:+UnlockExperimentalVMOptions, -XX:StartFlightRecording=maxsize=500k,filename=/dev/null,dumponexit=true, -Djcstress.console.printIntervalMs=3600000 ; but it is not that much important
jcstress is adding also: -XX:+-UseBiasedLocking, -XX:+-TieredCompilation; but I had seen a crash with both -XX:-UseBiasedLocking and -XX:+UseBiasedLocking and both -XX:-TieredCompilation and -XX:+TieredCompilation

In jdk8 runs, you can unluckily find a lot of:
java.lang.UnsupportedClassVersionError: org/openjdk/jcstress/.. or java.lang.NoSuchMethodError: java.lang.invoke.... Those are false negatives which are usually ignored by jcstress, but if real error is here, it is hidden among them.
You can see it in summary like `VM ERROR` instead of `skipped` (or ok, but skipped is also red, ok is green 🙂 ). Tahts why I'm recomending the AtomicLongFieldUpdater.atomic_getAndSet_set_short to run in loop (with JAVA_TOOL_OPTIONS="-XX:StartFlightRecording=maxsize=500k,filename=/dev/null,dumponexit=true"), as it do not suffer the UnsupportedClassVersionError/NoSuchMethodError pollution.

So on any aarch64, you can:
build latest jdk8 (I built it via temurin build script, but also other builds (eg fedora rpms) are affected)
wget https://ci.adoptium.net/view/Dependencies/job/dependency_pipeline/1542/artifact/jcstress/jcstress-20240222.jar
set -e ; while true; do
  export JAVA_TOOL_OPTIONS="-XX:StartFlightRecording=maxsize=500k,filename=/dev/null,dumponexit=true"
  ./java-1.8.0-openjdk-jdk8u462.b05-0.ojdk8~u~upstream.hotspot.release.sdk.el7.aarch64/bin/java -jar jcstress-20240222.jar -t org.openjdk.jcstress.tests.memeffects.basic.atomicupdaters.AtomicLongFieldUpdater.atomic_getAndSet_set_short
done

and you should hit it in 50-200 iterations. Note that my automated runs run it with -c2, but having higher/default value should cause the issue to appear earlier.

See attached log, and hserrors form such run.

Other seen methods where crash occured:
   o.o.j.t.atomicity.varHandles.fields.GetAndSetTest.GetAndSetChar
   o.o.j.samples.jmm.advanced.AdvancedJMM_10_WrongListReleaseOrder
   o.o.j.t.accessAtomic.varHandles.fields.opaque.StringTest
   o.o.j.t.acqrel.varHandles.arrays.acqrel.DoubleCharTest
   o.o.j.t.acqrel.varHandles.byteArray.little.acqrel.CharCharTest
   o.o.j.t.acqrel.varHandles.byteBuffer.direct.little.acqrel.LongByteTest
   o.o.j.t.acqrel.varHandles.byteBuffer.heap.little.volatiles.ShortByteTest
   o.o.j.t.acqrel.varHandles.fields.acqrel.IntByteTest
   o.o.j.t.acqrel.varHandles.fields.acqrel.ShortBooleanTest
   o.o.j.t.atomicity.buffers.CharBufferAtomicityTests.CharTest
   o.o.j.t.atomicity.primitives.perbyte.ByteAtomicityTest
   o.o.j.t.atomicity.varHandles.arrays.CAETest.CompareAndExchangeAcquireChar
   o.o.j.t.atomicity.varHandles.arrays.CAETest.CompareAndExchangeReleaseInt
   o.o.j.t.atomicity.varHandles.arrays.WeakCASTest.WeakCompareAndSetChar
   o.o.j.t.atomicity.varHandles.byteBuffer.direct.big.GetAndSetTest.GetAndSetFloat
   o.o.j.t.atomicity.varHandles.fields.CASTest.CompareAndSetLong
   o.o.j.t.atomicity.varHandles.fields.WeakCASContendStrongTest.WeakCompareAndSetPlainDouble
   o.o.j.t.atomicity.varHandles.fields.WeakCASTest.WeakCompareAndSetReleaseByte VM ERROR
   o.o.j.t.atomics.integer.AtomicIntegerArrayPairwiseTests.GetAndInc_WCAS
   o.o.j.t.atomics.integer.AtomicIntegerFieldUpdaterPairwiseTests.GetAndSet_CAS VM ERROR
   o.o.j.t.atomics.integer.AtomicIntegerPairwiseTests.AddAndGet_Set
   o.o.j.t.coherence.arrays.sync.FloatTest
   o.o.j.t.coherence.varHandles.byteArray.little.opaque.DoubleTest
   o.o.j.t.copy.arraycopy.arrays.large.plain.CharTest
   o.o.j.t.copy.clone.arrays.small.volatiles.ByteTest
   o.o.j.t.copy.manual.objects.plain.FloatTest
   o.o.j.t.initClass.fields.sync.IntTest
   o.o.j.t.init.fields.volatiles.BooleanTest
   o.o.j.t.locks.mutex.ReentrantLockMutexTests.I_N.L_TLt
   o.o.j.t.locks.mutex.ReentrantRWLockMutexTests.I_F.TLt_TLt
   o.o.j.t.locks.mutex.SynchronizedMutexPoolTest
   o.o.j.t.locks.stamped.StampedLockPairwiseTests.RLI_tUR.WLI_tUW
   o.o.j.t.locks.stamped.StampedLockPairwiseTests.RL_URs.WLI_Us
   o.o.j.t.locks.stamped.StampedLockPairwiseTests.tRLt_tUR.tWLt_Us
   o.o.j.t.locks.stamped.StampedLockPairwiseTests.tRLt_URs.tWLt_UWs
   o.o.j.t.locks.stamped.StampedLockPairwiseTests.tRL_URs.aWL_U
   o.o.j.t.memeffects.basic.atomic.AtomicBoolean.atomic_get_set_double
   o.o.j.t.memeffects.basic.atomic.AtomicBoolean.atomic_get_set_short
   o.o.j.t.memeffects.basic.atomicupdaters.AtomicIntegerFieldUpdater.atomic_compareAndSet_getAndAdd_long
   o.o.j.t.memeffects.basic.atomicupdaters.AtomicIntegerFieldUpdater.atomic_getAndAdd_getAndSet_long
   o.o.j.t.memeffects.basic.atomicupdaters.AtomicLongFieldUpdater.atomic_getAndSet_set_short
   o.o.j.t.tearing.arrays.small.sync.DoubleTest

But except o.o.j.t.atomicity.varHandles.fields.GetAndSetTest.GetAndSetChar they seems to be ppoping out in same chance. The o.o.j.t.atomicity.varHandles.fields.GetAndSetTest.GetAndSetChar have slightly higher popup rate.