Request for discussion: rewrite invokeinterface dispatch, JMH benchmark

[Andrew Haley]

On 10/9/24 10:18, Dmitry Chuyko wrote:
> If you remember
> https://github.com/openjdk/jdk/pull/13460, example micro-benchmark
> improvements for x86 were ~10% and only ~3% in Naive Bayes.

Ah, yes. Good point. I guess now we know why.

> Those results
> greatly varied depending on the CPU microarchitecture and some CPUs also
> showed almost no difference (some data is in the PR). However, we did not
> complicate predictability in benchmarks. Also, other micro-benchmarks were
> not too sensitive to the change at all. It is hard to say what are the
> patterns in applications where dispatching has significant weight (which
> can be as high as 15%), but won't be surprising to meet both
> predictable and not predictable scenarios. It might be that the predictable
> case is more common but the non-predictable case brings more pain when it
> happens.

Indeed. My guess would be that if it's as high as 15%, that's probably because
branch prediction fails.

My thinking is that I'll optimize for the unpredictable case, and the result
of that work won't much affect the performance in the highly-predictable one.

My goal with this work, apart from removing code to handle the stubs and the
unverified entry points, is to make invokeinterface performance more stable
and predictable, especially in cases where the CPU can't predict accurately
what'll happen.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671