Well I have a prototype GWT in place, but I'm having trouble getting invokeExact to work. As far as I can tell, incoming arguments should match the handle type just fine, but I'm getting this error:
InvokeDynamicSupport.java:934:in `gwt': java.lang.invoke.WrongMethodTypeException: (Lorg/jruby/runtime/ThreadContext;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/runtime/builtin/IRubyObject;Ljava/lang/String;Lorg/jruby/runtime/builtin/IRubyObject;)Lorg/jruby/runtime/builtin/IRubyObject; cannot be called with a different arity as ([Ljava/lang/Object;)Ljava/lang/Object; The diff as it stands right now is here: https://gist.github.com/987939 - Charlie On Mon, May 23, 2011 at 7:23 PM, Tom Rodriguez <tom.rodrig...@oracle.com> wrote: > > On May 23, 2011, at 5:13 PM, Charles Oliver Nutter wrote: > >> On Mon, May 23, 2011 at 6:17 PM, Rémi Forax <fo...@univ-mlv.fr> wrote: >>> On 05/24/2011 12:44 AM, Tom Rodriguez wrote: >>>> I haven't been following 292 that closely but it used to be a piece of >>>> code that did precisely that. >>>> >>>> + private Object invoke_L0() throws Throwable { >>>> + if ((boolean) test.invokeExact()) >>>> + return target.invokeExact(); >>>> + return fallback.invokeExact(); >>>> + } >>>> >>>> It looks like it was reworked at some point to use selectAlternative but >>>> the optimizer was never updated to deal with it properly. It's not >>>> particularly hard, we just need to generate code like we would for a >>>> bimorphic call site. The current code expects to either get a constant or >>>> something else and doesn't inline if it's something else. In this case we >>>> have a Phi of two constants which we just need to split. >> >> I'll give it a shot. I'll put together a benchmark that produces >> "effectively monomorphic" calls at the invokedynamic call site, but >> which uses an intermediate hand-written piece of Java code (that ends >> up polymorphic) in place of GWT. >> >> Obviously GWT should not fail this badly in final release, but if this >> works it could mean many, many other patterns will too. And it will >> definitively answer the question about whether such a case inlines in >> current logic. > > You can also just wait for a fix. I've started writing the logic for it and > just need to duplicate the guard. We should be able to have this fixed for > JDK7. > > tom > >> >>> The main problem of writing your own variant is that you will have to >>> write 256 * (number_of_primitive_type + 1) variants. >>> The main idea of GWT (and all other method handle combiners) is that >>> they provide a way to get such polymorphic variant >>> without coding all combinations. >>> >>> The benefit is also that these combiners are known by the VM that can >>> provide >>> dedicated path that are more efficient, >>> by ex, the arguments of GWT is pushed only once and used by the test >>> *and* the target (or fallback) >>> or better guarantee about how trees of combiners are inlined. >> >> I am not currently specializing any call paths for primitives, but >> that will come soon. For experiment's sake, I only need to provide one >> such GWT replacement to test fib (no block passed, single IRubyObject >> argument) and one more for the dispatch bench (no block, no args). >> We'll see how it looks. >> >> - 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 > _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
