RFR: 8305959: x86: Improve itable_stub [v6]

[Boris Ulasevich]

On Mon, 5 Jun 2023 10:10:22 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 updated the pull request incrementally with one additional commit since the last revision:
> 
>   push/pop(temp_get) -> push/pop(rdx)

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/13460#issuecomment-1580589791