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

[Rémi Forax]

f.foo() is a megamorphic call so the inlining cache does not work,
too many possible receiver types, so the inlining cache tree
is like a linked list, painfully.
With a language like Java, the VM will fallback to use
a vtable dispatch, you have no inlining but it's faster than
either update the inlining cache each time or to crawle the linked list.

So the idea here is to do exactly the same thing and simulate a vtable.
Because it's a dynamic language, you can't construct a vtable
but you can construct a dynamic lookup table for this precise call site.

I've tried to explain this pattern at the JVM Summit last year,
but I'm not sure someone even understand me :(
Anyway, take a look to the sample bi-morphic cache in the cookbook [1],
look for the comment 'bimorphic cache defeated', the DispatchMap
is what you' looking for.

Rémi
[1] 
http://code.google.com/p/jsr292-cookbook/source/browse/trunk/bimorphic-cache/src/jsr292/cookbook/bicache/RT.java

On 05/08/2012 12:18 AM, Jochen Theodorou wrote:
> 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
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev