RFR: 8305959: x86: Improve itable_stub [v2]

[Andrew Haley]

On Fri, 26 May 2023 08:10:09 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).
>
> Boris Ulasevich has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains three new commits since the last revision:
> 
>  - readability rework
>  - cleanup
>  - 8305959: x86: Improve itable_stub

Marked as reviewed by aph (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13460#pullrequestreview-1445633922