Duby dynamic dispatch has landed!

[Charles Oliver Nutter]

I will put together a duby-complete.jar that includes my bootstrap and
requires you to provide Attila's dynalang stuff. I also posted a blog
entry on how to build your own duby-complete; the missing piece is
just additionally compiling and linking in
src/org/jruby/duby/DynalangBootstrap.java:

http://blog.headius.com/2010/04/getting-started-with-duby.html

On Mon, Apr 5, 2010 at 6:16 PM, John Rose <john.r.rose at oracle.com> wrote:
> The sources are changing rapidly at this point; I'm working on invokeGeneric.  If you send me a JAR which which can run stand-alone, I can use it as a regression test.
>
> -- John
>
> On Apr 2, 2010, at 2:36 PM, Attila Szegedi wrote:
>
>> On 2010.03.25., at 3:17, Charles Oliver Nutter wrote:
>>
>>> For Attila: I had to remove a spreadArguments handle you used for
>>> re-binding the method...not sure why. Here's the diff:
>>
>> Turns out, now the MethodHandle.invokeVarargs() actually does the whole convert-to-generic-and-invoke-as-vararg, so I committed the definitive solution for it now, which is simply:
>>
>> Index: DynamicLinkerImpl.java
>> ===================================================================
>> --- DynamicLinkerImpl.java    (revision 233)
>> +++ DynamicLinkerImpl.java    (revision 228)
>> @@ -111,6 +111,12 @@
>>         // Invoke the method. Note we bypass the guard, as the assumption is
>>         // that the current arguments will pass the guard (and there actually
>>         // might be no guard at all).
>> -        return guardedInvocation.getInvocation().invokeVarargs(arguments);
>> +        final MethodHandle invocation = guardedInvocation.getInvocation();
>> +        final MethodType genericType = invocation.type().generic();
>> +        final MethodHandle genericizedInvocation =
>> +            MethodHandles.convertArguments(invocation, genericType);
>> +        final MethodHandle spreadInvocation = MethodHandles.spreadArguments(
>> +                genericizedInvocation, SPREAD_GENERIC_INVOCATION);
>> +        return MethodHandles.invoke(spreadInvocation, arguments);
>>     }
>> }
>>
>> (Mind you, this is a reverse diff, but I'm too sleepy now to fix it; just swap + and -)
>>
>> I think the problem was in the fact that the (now deprecated) MethodHandles.invoke() used to behave as "invokeExact" in the last August's builds (so that's why I had to genericize + spread explicitly), while now it maps to MethodHandle.invokeVarargs(), so in addition to it being deprecated, its behaviour was also changed in the past half a year and that broke things, as you have yourself experienced :-).
>>
>> Should be good now.
>>
>> BTW, Stephen Bannasch's MLVM build works completely okay - I abandoned the attempt to now build my own as it didn't work out quickly and I didn't want to waste a lot of time; his version + Java sources from Mercurial seem sufficient for debugging.
>>
>> I'm still not back to the old 6 unit test errors, but this patch reduced them from 18 to 8; seems there are still two genuine new issues.
>>
>> Attila.
>>
>>>
>>> Index: src/org/dynalang/dynalink/support/DynamicLinkerImpl.java
>>> ===================================================================
>>> --- src/org/dynalang/dynalink/support/DynamicLinkerImpl.java (revision 232)
>>> +++ src/org/dynalang/dynalink/support/DynamicLinkerImpl.java (working copy)
>>> @@ -115,8 +115,6 @@
>>>        final MethodType genericType = invocation.type().generic();
>>>        final MethodHandle genericizedInvocation =
>>>            MethodHandles.convertArguments(invocation, genericType);
>>> -        final MethodHandle spreadInvocation = MethodHandles.spreadArguments(
>>> -                genericizedInvocation, SPREAD_GENERIC_INVOCATION);
>>> -        return MethodHandles.invoke(spreadInvocation, arguments);
>>> +        return MethodHandles.invoke(genericizedInvocation, arguments);
>>>    }
>>> }
>>>
>>> I committed a built version with this hack...no tests, etc yet for
>>> Duby's "dynamic" type, but that will come soon.
>>>
>>> BTW, what's the current state of the art for emitting .java with an
>>> invokedynamic in it? Duby also has a .java backend, so I'll need to
>>> add indy support there as well (somehow).
>>>
>>> - Charlie
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>