dropArguments still NYI?

[Charles Oliver Nutter]

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