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