RFR: 8305959: Improve itable_stub

[Paul Hohensee]

On Thu, 13 Apr 2023 14:33:52 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> 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).

Looks good, other than a comment nit.

src/hotspot/cpu/x86/vtableStubs_x86_32.cpp line 186:

> 184:   const Register recv_klass_reg     = rsi;
> 185:   const Register holder_klass_reg   = rax; // declaring interface klass (DECC)
> 186:   const Register resolved_klass_reg = rdi; // resolved interface klass (REFC)

Please update the previous "Most registers are in use" comment.

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

Changes requested by phh (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13460#pullrequestreview-1433544548
PR Review Comment: https://git.openjdk.org/jdk/pull/13460#discussion_r1198369203