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

Reply via email to