On Tue, 21 Sep 2021 15:06:49 GMT, Claes Redestad <redes...@openjdk.org> wrote:
> > If you look at "Poly" results, spinning MHInvoker/VHInvoker classes for
> > each instance of Method/Field does not help at all.
>
> The added indirection in the "Poly" test might cause the code to fall off the
> inlining cliff, so that any constant folding becomes unlikely to happen. I
> agree that this might be closer to what happens in a real app, and as a data
> point it does show that the MHInvoker/VHInvoker optimizations might have been
> misguided.
It is not the added indirection (I can add an indirection in the "Var" case too
and benchmark would not change), but the variation of Method/Field instances
used at the same call-site. When there is only one instance ("Var" case),
delegating invocation of a MH to a MHInvoker somehow optimizes speculatively
with a guard that just checks that the same MHInvoker class is used each time
and further code is generated with constant MH.
Such speculative optimization does not happen with non-constant MHs
unfortunately despite the fact that there is only one MH instance.
But in "Poly" case, generated MHInvoker classes don't help as there are
multiple such classes and the speculative optimization falls apart (or is never
even tried).
-------------
PR: https://git.openjdk.java.net/jdk/pull/5027
