Interface calls

[Tom Rodriguez]

For any vanilla interface call you have to do a search in the itable  
for the appropriate method to call. This is the worst case behaviour  
of an interface call and is the default in the interpreter.  C1 and C2  
may be able to do better in a couple ways.  The first is that the type  
of the actual object may be more precise than the interface type of  
the invoke, allowing you to bind it like a virtual call.  This will  
often happen as a result of inlining but it assumes your compiler has  
at least a minimal type system to make that type visible.  There are  
cases where a method local type flow might allow you to bind directly  
without going through an interface.  Consider the following Java code:

List l = new ArrayList();
l.add("foo");

javac will emit an invokeinterface of List.add instead of emitting an  
invokevirtual of ArrayList.add because it will use the declared type  
of l instead of the actual type.  In this case a type flow should be  
able to tell you that the receiver is actually an ArrayList.  You can  
use ciMethod::resolve_invoke to map from the interface method back to  
the method you'd use an invokevirtual on.

C2 also uses type profiling in the interpreter to get a good guess of  
the actual type and emits a guarded call to the most frequent receiver  
type which does a good job of devirtualizing interface calls.

C1 has an optimization where if an interface has only a single  
implementor it will assume that all references to that interface must  
be of the implementor class.  This of course involves a dynamic guard  
since interface types are completely untrustworthy.

The other potential fast path is the fact that all our call sites have  
an inline cache, so if the invokeinterface site is actually  
monomorphic then the call site dispatch will get you directly to the  
right method with a few extra dynamic checks in the unverified entry  
point.  This requires the ability to rewrite the call site though.   
You might be able to build something like that by hand and you can get  
a fair amount of mileage out of it.  It can be tricky to deal with the  
atomicity and invalidation issues though.

tom

On Jun 8, 2009, at 8:22 AM, Gary Benson wrote:

> Hi all,
>
> Shark's implementation of invokeinterface currently mirrors what the
> interpreter does, and I'm trying to rewrite it to be more efficient.
> The current implementation pulls the index from the constant pool,
> which is ugly.  Is it possible to get this from the typeflow at
> compile time?  I tried looking to see how opto does it, but I don't
> really understand how opto does calls at all :(
>
> Cheers,
> Gary
>
> -- 
> http://gbenson.net/