Dirt-simple dynamic dispatch bootstrapper built into JDK?

[Attila Szegedi]

On 2010.03.23., at 6:17, Charles Oliver Nutter wrote:

> Hey, maybe I missed something, but it seems like there's a need for a
> "default" invokedynamic bootstrap. For example, I hacked invokedynamic
> bytecode emitting into Duby, so that this code:
> 
> def foo(a:dynamic)
>  a.size
>  a.elementAt(0)
> end
> 
> Emits this bytecode:
> 
>  public static java.lang.Object foo(java.lang.Object);
>    Code:
>       0: aload_0
>       1: invokedynamic #10,  0             // NameAndType
> size:(Ljava/lang/Object;)Ljava/lang/Object;
>       6: pop
>       7: aload_0
>       8: iconst_1
>       9: invokedynamic #13,  0             // NameAndType
> elementAt:(Ljava/lang/Object;I)Ljava/lang/Object;
>      14: areturn
> 
> Now rather than me shipping my own bootstrapper that just does normal
> Java method selection, it would be nice if there were one built into
> the JDK. It seems like a lot of folks playing with invokedynamic will
> want a simple fallback that just does Java invocation.
> 
> Is there anything like this in indy right now?

Nope, but there's in my MOP library :-)

> * Take the signature (minus the passed java/lang/Object) and try to
> look up a method on the actual target
> * If that fails, use the actual types of the arguments to perform the
> same search
> * If that fails, throw some interesting runtime error
> * If we find a method, bind it with a simple class equality type guard

This is pretty much what

<http://dynalang.svn.sourceforge.net/viewvc/dynalang/trunk/invoke/src/org/dynalang/dynalink/beans/BeansLinker.java?revision=211&view=markup>

and its friend classes (SimpleDynamicMethod and OverloadedDynamicMethod) in the package do - linkage following Java linking rules, using actual argument types at runtime.  
 
> * Stack bindings for additional classes as they are encountered
> possibly caching at a JVM level the sets of target+args we've seen

Admittedly, I don't provide this, just a monomorphic relinkable call site at <http://dynalang.svn.sourceforge.net/viewvc/dynalang/trunk/invoke/src/org/dynalang/dynalink/MonomorphicCallSite.java?revision=209&view=markup> but nothing stops you from taking its superclass RelinkableCallSite <http://dynalang.svn.sourceforge.net/viewvc/dynalang/trunk/invoke/src/org/dynalang/dynalink/RelinkableCallSite.java?revision=187&view=markup> and rewrite it to support a cascade of guardWithTest()s for various target classes.

The OverloadedMethod class actually has an argTypesToMethods map, that caches argTypes->method selection for overloads. Each instance of OverloadedMethod is specific to (target class, call site signature) and only contains the subset of overloaded methods that are applicable for the particular call site signature; it'll dispatch based on argTypesToMethods map on each invocation - that's pretty much the best you can do in the case where multiple overloads match a call site signature... 

There's plenty of opportunities for various optimizations in there though. I.e. OverloadedMethod instances could be uniqued for call sites with identical signatures (they aren't currently because that can have memory management implications, so then that needs to be dealt with too). I'm favoring code clarity over speculative optimizations, and I'm favoring necessary optimizations over code clarity (if they can't be done preserving said clarity), so there's not much optimizations in there as I don't have information on necessary optimizations *yet*... (nudge, wink).


> - Charlie

Attila.

--
home: http://www.szegedi.org
twitter: http://twitter.com/szegedi
weblog: http://constc.blogspot.com