invokeinterface on sealed interfaces
david.holmes at oracle.com
Sat May 22 02:38:43 UTC 2021
Probably something best discussed on hotspot-dev (cc'd) or perhaps
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 information about the jdk-dev