RFR: 8342826: Improve performance of oopDesc::klass() after JDK-8305895

[Stefan Karlsson]

On Mon, 11 Nov 2024 17:32:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Before intergration of JEP 450, a number of minor regressions have been identified. The root-cause of those is the additional flag-check for UseCompactObjectHeaders in a couple of hot code-paths. This change addresses those cases by introducing a new helper class ObjLayout, which initializes some global state depending on the flags, and use that state later, instead of loading and checking multiple flags in hot paths.
> 
> This solution is not great. The real fix will eventually be to get rid of UseCompressedClassPointers in a first step, and later also get rid of UseCompactObjectHeaders, and settle on a single object layout. But we are not there, yet, and it will take several (or many) releases to get there. In the meantime, the proposed change eliminates the remaining known regressions.
> 
> Relevant benchmarks:
> 
> DaCapo:pmd (less is better)
> pre-jep450:  703.67
> mainline:  729.38
> jdk8342826:  704.25
> 
> CryptoRsa (more is better)
> pre-jep450: 9315.719 ops/min
> mainline: 10109.509 ops/min
> jdk8342826: 10272.161 ops/min
> 
> 
> Throw.throwWith64Frames microbenchmark
> Before JEP 450 (605396280d5ea225828da4ed688068334a15e122)
> Throw.throwWith64Frames  avgt   40  3943.690 ± 15.456  ns/op
> Mainline
> Throw.throwWith64Frames  avgt   40  4083.029 ± 12.044  ns/op
> JDK-8342826
> Throw.throwWith64Frames  avgt   40  3973.082 ± 12.956  ns/op

Could you make an experiment where you just force-inline `oopDesc::klass()` with `ALWAYSINLINE` and compare that to the proposed patch? When I investigated one regression a non-inlined `klass()` was prominent in the JEP-450 code but not in the baseline.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22020#issuecomment-2475714783