Looking at Renaissance benchmarks, I notice that some benchmarks like scala-doku are significantly slower with Shenandoah in comparison with other collectors:

$ build/linux-aarch64-server-release/images/jdk/bin/java -jar ~/renaissance-jmh-0.16.0.jar ScalaDoku -wi 3 -i 3 -f 1 --jvmArgs "-Xmx8g -Xms8g -XX:+AlwaysPreTouch -XX:+UseParallelGC"

Benchmark         Mode  Cnt     Score     Error  Units
JmhScalaDoku.run    ss    3  2160.655 ± 364.043  ms/op

$ build/linux-aarch64-server-release/images/jdk/bin/java -jar ~/renaissance-jmh-0.16.0.jar ScalaDoku -wi 3 -i 3 -f 1 --jvmArgs "-Xmx8g -Xms8g -XX:+AlwaysPreTouch -XX:+UseShenandoahGC"

Benchmark         Mode  Cnt     Score     Error  Units
JmhScalaDoku.run    ss    3  3843.770 ± 740.348  ms/op


perfasm shows the hotspot is in the "dmb ishld" in nmethod entry barrier.

....[Hottest Region 2]..............................................................................
c2, scala.collection.immutable.SetIterator::next, version 1, compile id 893

              0x0000ffffa8599008:   nop
            [Entry Point]
              # {method} {0x0000fffe789eb008} 'next' '()Ljava/lang/Object;' in 'scala/collection/immutable/SetIterator'
              #           [sp+0x30]  (sp of caller)
              0x0000ffffa859900c:   ldr w8, [x1, #8]
              0x0000ffffa8599010:   ldr w10, [x9, #8]
              0x0000ffffa8599014:   cmp w8, w10
          ╭   0x0000ffffa8599018:   b.eq        0x0000ffffa8599020  // b.none
          │   0x0000ffffa859901c:   b   0x0000ffffa848ec60          ;   {runtime_call Shared Runtime ic_miss_blob}
          │ [Verified Entry Point]
   0.19%  ↘   0x0000ffffa8599020:   sub x9, sp, #0x14, lsl #12
   0.09%      0x0000ffffa8599024:   str xzr, [x9]
   0.09%      0x0000ffffa8599028:   sub sp, sp, #0x30
   0.09%      0x0000ffffa859902c:   stp x29, x30, [sp, #32]
   0.09%      0x0000ffffa8599030:   ldr w8, 0x0000ffffa8599174
   0.07%      0x0000ffffa8599034:   dmb ishld
   7.22%      0x0000ffffa8599038:   ldr w9, [x28, #32]
   0.08%      0x0000ffffa859903c:   cmp w8, w9


It makes sense that it affects some benchmarks that are not as deeply inlined. Erik did JDK-8290700, which ported a new way to sync up nmethod barriers, conc_instruction_and_data_patch, from Generational ZGC repository into mainline. Generational ZGC have been using it since JDK 21. Switching Shenandoah to it like so:

diff --git a/src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.hpp b/src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.hpp
index a12d4e2beec..c89847b9d52 100644
--- a/src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.hpp
+++ b/src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.hpp
@@ -67,7 +67,7 @@ class ShenandoahBarrierSetAssembler: public BarrierSetAssembler {
                                         Register scratch, RegSet saved_regs);
 
 public:
-  virtual NMethodPatchingType nmethod_patching_type() { return NMethodPatchingType::conc_data_patch; }
+  virtual NMethodPatchingType nmethod_patching_type() { return NMethodPatchingType::conc_instruction_and_data_patch; }
 
 #ifdef COMPILER1
   void gen_pre_barrier_stub(LIR_Assembler* ce, ShenandoahPreBarrierStub* stub);

...makes Shenandoah perform on significantly better on this example workload:

Benchmark         Mode  Cnt     Score    Error  Units
JmhScalaDoku.run    ss    3  2616.273 ± 51.920  ms/op

We need to see what else should be done to support conc_instruction_and_data_patch in Shenandoah barriers.