While running SPECjbb2015 to compare our GCs between 17 and 21 I noticed a regression with Parallel GC that we hadn't seen before. The regression doesn't seem to be visible in all configuration and systems (our tuned automatic testing doesn't register it).

What I see is a pretty big drop in the critical-jOPS score when doing a compliant SPECjbb2015 run on a pretty large system with a 16GB heap. When starting to backtrack I realized the regression was quite new. From what I can tell it is caused by JDK-8305092. Taking the latest JDK 21 and just backing this change out removes the regression I see. Looking at the patch it is not obvious to me why it would cause this regression. It could be that the SPECjbb2015 source code, which is making use of TimeUnit.NANOSECONDS.sleep(), is now somehow starting to behave differently and this is causing the regression. I have no evidence for that just wanted to point out that there are sleeps in the benchmark that will now have better granularity, from what I can tell those sleeps are still around 20ms. An alternative is that the finer granularity in some cases lead to additional parks instead of terminating the sleep, but haven't gotten around to look at this yet.

Doing a compliant run is very time consuming and I can also see the regression when doing fixed injection rate runs and looking at the resulting application latencies (rt-curve data) in the report generated by the benchmark. Here is the data from a short run with a very recent JDK 21 master:
---
===================================
Iteration;min;median;90-th percentile;95-th percentile;99-th percentile;max
1.0;300.0;5500.0;15000.0;17500.0;71000.0;98000.0
2.0;300.0;5200.0;14600.0;16800.0;66000.0;95000.0
3.0;300.0;5200.0;14400.0;17200.0;69000.0;91000.0
4.0;300.0;5300.0;15800.0;18100.0;74000.0;88000.0
5.0;300.0;5200.0;14500.0;16800.0;73000.0;94000.0
6.0;300.0;5000.0;14900.0;17500.0;71000.0;101000.0
7.0;300.0;5200.0;14300.0;17500.0;72000.0;91000.0
8.0;300.0;5200.0;15100.0;17800.0;73000.0;92000.0
9.0;300.0;5200.0;14500.0;17200.0;71000.0;95000.0
---

Compared to the same recent master with JDK-8305092 backed out:
---
===================================
Iteration;min;median;90-th percentile;95-th percentile;99-th percentile;max
1.0;300.0;3900.0;13100.0;15700.0;40000.0;96000.0
2.0;300.0;3700.0;13100.0;15600.0;22000.0;85000.0
3.0;300.0;3800.0;13500.0;16200.0;19900.0;95000.0
4.0;300.0;2900.0;12400.0;15400.0;19700.0;96000.0
5.0;300.0;3500.0;13300.0;16000.0;19800.0;104000.0
6.0;300.0;1900.0;13200.0;15800.0;19800.0;83000.0
7.0;300.0;3000.0;13300.0;15500.0;21000.0;95000.0
8.0;300.0;3600.0;13300.0;16000.0;25000.0;94000.0
9.0;300.0;2600.0;13800.0;16500.0;25000.0;94000.0
---

We can see that the both the median and p99 times are lower with the change backed out. When running with G1 I only see a clear difference in the median times for fixed IR runs, the compliant runs are not affected. Likely because the p99 times are not really affected and that is what is stearing the critical-jOPS score.