invokeinterface on sealed interfaces

[Vitaly Davidovich]

https://wiki.openjdk.java.net/display/HotSpot/InterfaceCalls is an old but
(I believe) still accurate description of how invokeinterface is dispatched
(if not monomorphized by the JIT).  In short, it doesn’t look up the method
by name but it does walk the receiver (ie object on which method is being
invoked) class’s list of interfaces to ensure it implements the interface
in question.  Once found, there’s an itable (similar in concept to vtable)
associated with that class’s implementation of the interface.

As for the more general question around dispatch performance,
https://shipilev.net/blog/2015/black-magic-method-dispatch/ is a good
writeup by Aleksey.  While some things may look expensive (eg
invokeinterface), the high tier JITs typically do a good job of making them
more efficient, leveraging runtime callsite type profiling.

Hope that helps.

On Fri, May 21, 2021 at 10:39 PM David Holmes <david.holmes at oracle.com>
wrote:

> Hi,
>
> Probably something best discussed on hotspot-dev (cc'd) or perhaps
> hotspot-compiler-dev.
>
> Disclaimer: I'm not a JIT expert. :)
>
> On 22/05/2021 11:50 am, - wrote:
> > Greetings all,
> > I have heard of a myth against using interfaces, namely on how
> > invokeinterface is slower than invokevirtual since concrete class methods
> > to call, with known indices in the method table, can be found more easily
> > than interface methods, which always require a lookup by name.
>
> Not sure about that part.


>
> > Another myth I've heard is that JVM may decide to construct a temporary
> > table for interface dispatches as well, but the table would be discarded
> > once another class is discovered in the interface hierarchy and the
> > performance would slow back down.
>
> This happens for classes and virtual methods too. Class Hierarchy
> Analysis (CHA) can be used to devirtualise a call-site if we know there
> can't be subclasses to distinguish. If a subclass is subsequently loaded
> then that analysis has to be discarded and the code deoptimised so the
> call site is virtualised again.
>
> > I wonder if these two claims are right; unfortunately, I am no good at
> the
> > VM internals and can't verify them. But if they are true, I wonder if
> > invokeinterface calls on sealed interface methods would enjoy a
> performance
> > boost and have its performance brought closer to that of invokevirtual
> > calls. It seems that the sealed class design not only provides clearer
> > apis, but also allow the VM to better optimize code.
>
> I'm not sure if there is much scope for additional optimisation beyond
> the fact that if all subclasses are known when CHA is applied then we
> know it can't be invalidated later. JIT compiler folk may be able to say
> more.
>
> Cheers,
> David
>
> > Best
> >
>
-- 
Sent from my phone