Dirt-simple dynamic dispatch bootstrapper built into JDK?

[Charles Oliver Nutter]

Thanks Attila! Given that I don't want to write my own dispatcher,  
your MOP will have it's first official customer in Duby. It will also  
have the dubious (pun intended) distinction of being Duby's first  
library dependency (only for dynamic invocation.

- Charlie (mobile)

On Mar 23, 2010, at 3:07 AM, Attila Szegedi <szegedia at gmail.com> wrote:

> 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
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev