JDK-8343648 : Dacapo:pmd performance regression due to non inlined method.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: New
  • Resolution: Unresolved
  • OS: linux
  • CPU: x86
  • Submitted: 2024-11-05
  • Updated: 2024-11-11
Related Reports
Relates :  
JDK-8314440 - Performance Testing Plan for Implementation of JEP 450: Compact Object Headers
Description
Dacapo:pmd has ~-5% performance regression on the CompactObjectHeaders branch when CompactObjectHeaders is not enabled.
The branch where regression is observed: https://github.com/rkennke/jdk/blob/JDK-8305895-v4-fast-klass

The issue is related to  "BacktraceBuilder::push()" called from "fill_in_stack_trace".
 BacktraceBuilder::push() marked as "inline" method and it's successfully inline in the mainline, but it's not inlined in CompactObjectHeaders branch.
Comments
With deeper profiling, it is obvious there are two critical paths: writing out things to backtrace and allocating objects. Both enter the low-level oopDesc methods, which now require more flag checking. The major offenders would be fixed with JDK-8342826, AFAICS, see the perf data above. I think we wait on JDK-8342826, and then confirm it does fix the Dacapo regression as well.
11-11-2024
Actually, I suspect the lack of inlining is symptom, not the cause. Deeper `perf` profiling shows the hotpath lies through `oopDesc::base_offset_in_bytes()`, due to exception building code entering here through `typeArrayOopDesc::*_at(_put)` accessors. With COH, `oopDesc::base_offset_in_bytes()` checks one more global flag. A dirty POC patch (8343648-dirty-cache.patch) shows that improvements are possible on that path, which recovers a significant part of the regression: ``` % CONF=linux-x86_64-server-release make test TEST=micro:Throw.throwWith64Frames MICRO=WARMUP_ITER=10 # Before Lilliput (605396280d5ea225828da4ed688068334a15e122) Throw.throwWith64Frames avgt 12 4057.901 ± 13.317 ns/op # At Lilliput (44ec501a41f4794259dd03cd168838e79334890e) Throw.throwWith64Frames avgt 12 4253.490 ± 9.863 ns/op # At Lilliput (44ec501a41f4794259dd03cd168838e79334890e) + 8343648-dirty-cache.patch Throw.throwWith64Frames avgt 12 4126.249 ± 17.416 ns/op # Mainline + Roman's WIP from JDK-8342826 Throw.throwWith64Frames avgt 12 4078.259 ± 19.364 ns/op ``` This looks similar to the issue Roman is already handling in JDK-8342826.
11-11-2024
Thank you, [~shade], yes that makes sense. This is the same problem that we have seen in oopDesc::klass(), and I'll fix it the same way as part of JDK-8342826.
11-11-2024
Assuming this exception-stack building path, we can probably reproduce it with targeted exceptions benchmarks. Seems to reproduce locally here with `Throw.throwWith64Frames` from the existing corpus.
11-11-2024
[~shade] No.
06-11-2024
Sergey, are you planning to work on this problem?
06-11-2024