RFR: 8305959: Improve itable_stub

Boris Ulasevich bulasevich at openjdk.org
Wed May 3 10:38:13 UTC 2023


Async profiler shows that applications spend up to 10% in itable_stubs.

The current inefficiency of itable stubs is as follows. The generated itable_stub scans itable twice: first it checks if the object class is a subtype of the resolved_class, and then it finds the holder_class that implements the method. I suggest doing this in one pass: with a first loop over itable, check pointer equality to both holder_class and resolved_class. Once we have finished searching for resolved_class, continue searching for holder_class in a separate loop if it has not yet been found.

This approach gives 1-10% improvement on the synthetic benchmarks and 3% improvement on Naive Bayes benchmark from the Renaissance Benchmark Suite (Intel Xeon X5675).

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

Commit messages:
 - cleanup
 - 8305959: Improve itable_stub

Changes: https://git.openjdk.org/jdk/pull/13460/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13460&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305959
  Stats: 258 lines in 5 files changed: 209 ins; 25 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/13460.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13460/head:pull/13460

PR: https://git.openjdk.org/jdk/pull/13460


More information about the hotspot-dev mailing list