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
[email protected]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
