JDK-8289161 : Regressions 2-3% on some Renaissance after 8275201
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 19
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: linux
  • CPU: x86_64
  • Submitted: 2022-06-24
  • Updated: 2022-10-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8275201 - C2: hide klass() accessor from TypeOopPtr and typeKlassPtr subclasses
Description
Renaissance-FutureGenetic	-2.06%
Renaissance-Mnemonics	-2.02%
Renaissance-PageRank	        -3.67%
Renaissance-ParMnemonics	-3.00%

I have been able to repro these on IceLake and CascadeLake type systems.

We are running renaissance-jmh-assembly-0.14.1.jar  , here are the run options:

FutureGenetic -t 1 -i 15 -wi 25 -f 10
JmhMnemonics -bm avgt -t 1 -w 9 -wi 10 -r 5 -i 10 -f 10  

PageRank requires jvmArgs: -XX:+IgnoreUnrecognizedVMOptions --add-opens=java.base/java.nio=ALL-UNNAMED --add-opens=java.base/sun.nio.ch=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED -XX:-IgnoreUnrecognizedVMOptions

PageRank      -bm avgt -t 1 -w 9 -wi 10 -r 5 -i 10 -f 5
ParMnemonics -bm avgt -t 1 -w 9 -wi 10 -r 5 -i 10 -f 10
Comments
I recently did some perf-testing and noticed a slight regression (a few percent) in SpecJBB 2015 with G1 and a 16GB heap. I've narrowed it down to show that at least part of the regression I noticed is caused by this change. The regression seem to be larger on older hardware and that's where I first notice it. On newer hardware the regression is smaller but still present, but there is no overall regression between JDK 18 and JDK 19. Hopefully the inlining improvements mentioned can remove this regression as well and I think it is a good idea to do some JBB15 testing with those changes when ready. I'm happy to help with that if needed.
31-10-2022
For the record, BKLG-1568 is an internal umbrella RFE for inlining improvements that [~iveresov] is working on.
31-08-2022
We most likely address this issue with Inlining improvements we are working on: BKLG-1568. We close this as dup after that. Keep it for now.
30-08-2022
Thanks [~ecaspole]. I have this patch: https://github.com/rwestrel/jdk/tree/types-refactoring-verif that keeps both logic from before JDK-8275201 and from after and checks that the same result is returned by both. From all the benchmarks you list, only PageRank triggers that verification code. The verification code finds that methods: com.esotericsoftware.kryo.serializers.FieldSerializer::<init> and org.apache.spark.rdd.RDD::partitions might compile differently. This 2 are not on the list of methods where time is spent as reported when the benchmark is run with -prof perfasm. As I said, JDK-8275201 is a refactoring change. This experiment should prove that even if it can sometimes change the way a method is compiled, the benchmarks are unaffected. That refactoring change is important because it's preparation work for JDK-6312651 (Compiler should only use verified interface types for optimization) a long standing piece of technical debt. If JDK-8275201 is backed out then JDK-6312651 won't happen. Given there's no reason to believe that what's observed is a bug, I would simply close this bug as will not fix.
19-08-2022
You might have to pull the code and build it for yourself: With a JDK 8 JAVA_HOME, $ tools/sbt/bin/sbt clean renaissanceJmhPackage The file will be in renaissance-jmh/target/
18-07-2022
JDK-8275201 is a refactoring change in preparation for a correctness change. One part of the change may cause the compiler to optimize differently. It's not expected to be common and it's also expected to always be beneficial. Because it is mostly a refactoring change, that this change could cause a performance regression seems unlikely. Where would I get renaissance-jmh-assembly? It's not on the renaissance website.
18-07-2022
ILW = small-ish regression on some benchmarks = LHH = P4
24-06-2022
[~roland], please take a look.
24-06-2022
AFAICT from +LogCompilation of PageRank, this JDK-8275201 change ends up changing the compilation order, which results in a lot of "fail: already compiled into a medium method" etc in the last compilations of the hottest methods. So, as that is a very common problem, if JDK-8275201 is a correctness change, we could accept it.
24-06-2022