Question about inlining caching by Hotspot and classes implementing an method from an interface

[Jochen Theodorou]

Hi all,

I have the feeling we have talked about this already, but I couldn't 
really find it and back then it was independend of invokedynamic... 
Anyway...


Assuming I have an interface Foo with a void method foo(). And assuming 
I have the class Bar0, Bar1 to BarN implementing that interface. Let us 
assume further I have code like this:


method(bar0)
method(bar1)
...
method(barN)

where bar0,bar1,..., barN are instance of the corresponding Bar classes 
and method is more or less this:

void method(Foo f){f.foo();}

I was thinking about how I would have to implement the call site checks 
for this case in invokedynamic in that method and the current approach 
would be to check for the implementation class, meaning BarX and meaning 
also to have an invalidation and reselection of the method each time 
method is called. This is surely not the optimal case. It surely would 
be better to check that f implements Foo... well or in the case here we 
can simply forget that check on the receiver... if that where 
reflection. But I think that does not work with MethodHandles I think. I 
guess I will need the reference to the implementation method instead and 
then also a guard for the receiver. Am I wrong? IS there a way around?

THis thought did lead me to another question.... how does the JVM do 
this for the pure bytecode case? Wouldn't the JVM do mostly the same? I 
mean add a receiver check for the implementation class, just to 
invalidate this site for each of the calls to method? Or how is it done 
there?

bye Jochen