dropArguments still NYI?

[Charles Oliver Nutter]

I found a fix for this by wiring up bindArgument. Patch is here:

http://gist.github.com/120648

Pretty naive, but it got my single test method working! I've pushed that 
update to jruby invokedynamic branch as well.

Next up would be combineArguments, and then I think I have enough to 
wire a straight-through path for non-exception-handling calls.

- Charlie

Charles Oliver Nutter wrote:
> John: You were right...I was confused by "qrefresh" which does not 
> refresh applied patches as I suspected. By running qrefresh after 
> updating the patch repo, I overwrote the updated indy with my original 
> one from pre-dropArguments. Mea culpa; it's working now.
> 
> But of course I now run into a new issue :) The handle resulting from 
> dropArguments appears to not support a subsequent insert of an argument. 
> So drop + insert leads to NYI.
> 
> Here's the new single test method:
> 
>      public static boolean test(CacheEntry entry, IRubyObject self) {
>          return entry.typeOk(self.getMetaClass());
>      }
> 
> Here's the base handle:
> 
>      private static final MethodHandle TEST = MethodHandles.dropArguments(
>  
> MethodHandles.lookup().findStatic(InvokeDynamicSupport.class, "test",
>                  MethodType.make(boolean.class, CacheEntry.class, 
> IRubyObject.class)),
>              1,
>              ThreadContext.class, IRubyObject.class);
> 
> Here's the next layer of dropArguments, for the arity-specific handle 
> (1-arity in this case):
> 
>      private static final MethodHandle TEST_1 = 
> MethodHandles.dropArguments(TEST, 2, String.class, IRubyObject.class);
> 
> And here's the insertArguments call, upon the first time a gWT is installed:
> 
>      private static MethodHandle createGWT(MethodHandle test, 
> MethodHandle target, MethodHandle fallback, CacheEntry entry, CallSite 
> site) {
>          MethodHandle myTest = MethodHandles.insertArgument(test, 0, entry);
>          MethodHandle myTarget = MethodHandles.insertArgument(target, 0, 
> entry);
>          MethodHandle myFallback = 
> MethodHandles.insertArgument(fallback, 0, site);
>          MethodHandle guardWithTest = 
> MethodHandles.guardWithTest(myTest, myTarget, myFallback);
>          return MethodHandles.convertArguments(guardWithTest, site.type());
>      }
> 
> I believe I'm doing all this right. Poking around the code now.
> 
> Charles Oliver Nutter wrote:
>> I saw jrose land a dropArguments fix a day or two ago, but it still 
>> seems to be coming up NYI for me:
>>
>> ~/projects/jruby ➔ JAVA_HOME=$MLVM_HOME JAVA_OPTS=$INDY_OPTS jruby -d -e 
>> "puts 1"
>> could not compile: -e because of: "null"
>> java.lang.ExceptionInInitializerError
>> 	at java.lang.Class.forName0(Native Method)
>> 	at java.lang.Class.forName(Class.java:186)
>> 	at 
>> org.jruby.compiler.impl.StandardASMCompiler.<clinit>(StandardASMCompiler.java:127)
>> 	at org.jruby.Ruby.tryCompile(Ruby.java:536)
>> 	at org.jruby.Ruby.tryCompile(Ruby.java:524)
>> 	at org.jruby.Ruby.runNormally(Ruby.java:505)
>> 	at org.jruby.Ruby.runFromMain(Ruby.java:361)
>> 	at org.jruby.Main.run(Main.java:268)
>> 	at org.jruby.Main.run(Main.java:113)
>> 	at org.jruby.Main.main(Main.java:97)
>> Caused by: java.lang.UnsupportedOperationException: NYI
>> 	at sun.dyn.MethodHandleImpl.dropArguments(MethodHandleImpl.java:301)
>> 	at java.dyn.MethodHandles.dropArguments(MethodHandles.java:1021)
>> 	at 
>> org.jruby.runtime.invokedynamic.InvokeDynamicSupport.<clinit>(InvokeDynamicSupport.java:388)
>>
>> Here's the code in syn/dyn/MethodHandleImpl.java:
>>
>>      public static
>>      MethodHandle dropArguments(Access token, MethodHandle target,
>>                                 MethodType newType, int argnum) {
>>          Access.check(token);
>>          throw new UnsupportedOperationException("NYI");
>>      }
>>
>> I certainly could have things applied incorrectly, but I could find no 
>> updates to MethodHandleImpl.java in patches/jdk/indy.patch
>>
>> - 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