This appeared in b5 retriage. Most visibile on Mac ARM but sort of visible on Windows.
Seems to be related to JDK-8297933
Comments
The regression here seems to be more due to the memory than to this C2 change JDK-8297933, there is no regression with a bigger fixed heap size.
24-04-2023
[~ecaspole] thanks for doing some further investigation. Closing it sounds good to me.
20-04-2023
At least on these Minis, this JMH is very sensitive to heap size and GCs happening during the run. If run with a really large heap "-Xms6g -Xmx6g -XX:NewSize=5g" so no GCs happen during the run, there is no regression with ParallelGC and maybe only 1% with G1.
There is usually 10-20K more 'non-profiled nmethods' in +PrintCodeCache in the 223 version, so there could be a little bit different cache behavior.
[~roland] I am satisfied to close this 'not an issue' etc, what do you think?
19-04-2023
[~roland] I agree, there is a small improvement on our linux-aarch64, on the same build where the mac-aarch64 has the regression. We will talk about it and get back to you.
07-04-2023
I can't reproduce this. I don't have access to an aarch64 mac so I ran it on some other linux aarch64 system and I see:
KeyAgreementBench.XDH.generateSecret XDH 255 XDH thrpt 40 4078.286 ± 5.146 ops/s
without the change and:
KeyAgreementBench.XDH.generateSecret XDH 255 XDH thrpt 40 4164.362 ± 38.784 ops/s
with it.
The JMH is javax.crypto.small.KeyAgreementBench.XDH.generateSecret
https://github.com/openjdk/jmh-jdk-microbenchmarks/blob/master/micros-jdk11/src/main/java/org/openjdk/bench/javax/crypto/small/KeyAgreementBench.java