renaissance benchmark performance regression

Since revision [1] I see performance regression on renaissance benchmark: the JmhScalaDoku bench timing [2] is intermittently executed normally or twice a usual time.

I reproduce it on AMD and AARCH. Warmup iterations increase does not help. On AMD it can be reproduced with -XX:-TieredCompilation option.

Perfasm Hottest Methods list is different. Good case:
 20.11% c2 scala.collection.immutable.ChampBaseIterator::searchNextValueNode, version 1086
 16.47% c2 scala.collection.immutable.SetIterator::next, version 933
 12.45% c2 scala.collection.ArrayOps$::count$extension, version 1013
 11.62% c2 scala.collection.IterableOnceOps::exists, version 1170

Bad case:
23.46% c2 java.lang.StringLatin1::indexOf, version 95
 16.71% c2 scala.collection.immutable.ChampBaseIterator::searchNextValueNode, version 1203
 12.32% c2 scala.runtime.java8.JFunction1$mcZI$sp::apply, version 982
 11.09% c2 scala.collection.immutable.SetIterator::next, version 1202
  9.80% c2 scala.collection.IterableOnceOps::count, version 931

If compare top lists, good case vs bad case, we see lambda+IterableOnceOps::count=22% > IterableOnceOps::exists=11% - actually it is the same code, the difference is in compilation order, when IterableOnceOps::exists is compiled first, it inlines and all the stuff. Tough, it does not explain double performance difference.

How to reproduce:

Renaissance benchmark build:
  git clone https://github.com/renaissance-benchmarks/renaissance
  cd renaissance
  git checkout be1e64f8221f727786bb66f177c9adb1f79e4ecc
  tools/sbt/bin/sbt renaissanceJmhPackage

JDK build:
  git clone https://github.com/openjdk/jdk
  cd jdk
  git checkout 6ff2d89ea11934bb13c8a419e7bad4fd40f76759
  bash configure --with-boot-jdk=/ws/jdk-18.0.1
  make
  
Benchmark run:
  ./build/linux-aarch64-server-release/jdk/bin/java -jar ../renaissance/renaissance-jmh/target/renaissance-jmh-0.13.0-86-gbe1e64f.jar -wi 4 -i 1 -f 5 Doku | grep ms/op
# Warmup Iteration 1: 6539.843 ms/op
# Warmup Iteration 2: 6677.075 ms/op
# Warmup Iteration 3: 6622.774 ms/op
# Warmup Iteration 4: 6653.434 ms/op
Iteration 1: 6610.787 ms/op
# Warmup Iteration 1: 6402.209 ms/op
# Warmup Iteration 2: 6875.695 ms/op
# Warmup Iteration 3: 6837.648 ms/op
# Warmup Iteration 4: 6834.374 ms/op
Iteration 1: 6855.812 ms/op
# Warmup Iteration 1: 4788.483 ms/op
# Warmup Iteration 2: 3543.175 ms/op
# Warmup Iteration 3: 3487.233 ms/op
# Warmup Iteration 4: 3495.347 ms/op
Iteration 1: 3514.971 ms/op
# Warmup Iteration 1: 4790.003 ms/op
# Warmup Iteration 2: 3421.466 ms/op
# Warmup Iteration 3: 3399.728 ms/op
# Warmup Iteration 4: 3398.471 ms/op
Iteration 1: 3419.831 ms/op
# Warmup Iteration 1: 6576.277 ms/op
# Warmup Iteration 2: 6706.094 ms/op
# Warmup Iteration 3: 6645.530 ms/op
# Warmup Iteration 4: 6592.679 ms/op
Iteration 1: 6635.751 ms/op
JmhScalaDoku.runOperation ss 5 5407.431 ± 6830.581 ms/op

[1]
https://github.com/openjdk/jdk/commit/6ff2d89ea11934bb13c8a419e7bad4fd40f76759
commit 6ff2d89ea11934bb13c8a419e7bad4fd40f76759
Author: Alan Bateman <alanb@openjdk.org>
Date: Thu Jun 2 09:02:37 2022 +0000

    8287496: Alternative virtual thread implementation that maps to OS thread

    Reviewed-by: rehn, mchung

[2]
Benchmark Mode Cnt Score Error Units
o.r.scala.sat.JmhScalaDoku.runOperation ss 6 3323.076 ± 16.377 ms/op
o.r.scala.sat.JmhScalaDoku.runOperation ss 6 6491.346 ± 38.552 ms/op
o.r.scala.sat.JmhScalaDoku.runOperation ss 6 6596.792 ± 67.552 ms/op
o.r.scala.sat.JmhScalaDoku.runOperation ss 6 3369.432 ± 123.580 ms/op
o.r.scala.sat.JmhScalaDoku.runOperation ss 6 3307.597 ± 63.008 ms/op
o.r.scala.sat.JmhScalaDoku.runOperation ss 6 6731.889 ± 52.736 ms/op
o.r.scala.sat.JmhScalaDoku.runOperation ss 6 6584.182 ± 53.898 ms/op
o.r.scala.sat.JmhScalaDoku.runOperation ss 6 6726.016 ± 25.500 ms/op