invokeinterface on sealed interfaces

[David Holmes]

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
>