> De: "Charles Oliver Nutter" <head...@headius.com> > À: "JVM Languages" <jvm-languages@googlegroups.com> > Envoyé: Jeudi 21 Juillet 2016 03:21:36 > Objet: Re: [jvm-l] Tool to convert call sites into invokedynamic?
> On Wed, Jul 20, 2016 at 12:41 PM, Remi Forax < fo...@univ-mlv.fr > wrote: >> yes, the rewriting part is easy, the question is more how to find the call >> you >> want to rewrite and how to find the bootstrap method and the bootstrap >> arguments associated with that call. > At the moment I am using my own non-indy call sites, one per actual site in > the > Java code. The call sites are all very straightforward: > sites(context).some_method.call(context, caller, target, args...) > Where sites is a private static method that gets the right box of call sites, > some_method is one of those call sites for calling "some method" and the call > logic does the monomporphic cache. > It should not be hard to see this pattern in code and rewrite it, but it won't > be a simple invokevirtual => invokedynamic. >> Charles, given that i will be locked up in a flying box for a little more >> that >> 10 hours soon, >> if you have precise answers to these two questions, i can write a tool for >> you >> during that time. > What I want is a way to say "take all call sites that look like X and turn > them > into indy call sites that do X the right way". here is a prototype: https://github.com/forax/jruby-methodcall-optimizer it recognize sites(context) . some_method . call(context, caller, target, " arg1 " , " arg2 " ); and transform it too 6: aload_1 7: pop 8: aload_1 9: aload_2 10: aload_3 11: iconst_2 12: anewarray #5 // class java/lang/Object 15: dup 16: iconst_0 17: ldc #6 // String arg1 19: aastore 20: dup 21: iconst_1 22: ldc #7 // String arg2 24: aastore 25: invokedynamic #74, 0 // InvokeDynamic #0:some_method:(LContext;Ljava/lang/Object;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; the pop at line 7 is here because the pattern load the context twice, and as you can see the arguments are boxed in an array. >> A fun way to design such filter is to create a class that declares methods >> that >> uses the @PolymorphicSignature, >> with that the compiler will not try to box the arguments and it will be >> easier >> to substitute a call to >> a method of this call by an invokedynamic. > There's lots of annotations I'd love to play with from java.lang.invoke, but > is > there any way to do it without runtime tricks? as far as i know, no, but you want a tool that rewrite bytecode (so introducing annotation can be done at the same time, i.e. translating your custom annotation into jdk internal one). > FWIW, a contrived benchmark that uses a lot of dynamic calling from Java is > already 3x faster by introducing simple monomorphic caches. > This work is the first step. > * Get dynamic calls from Java caching in SOME way. > * Get dynamic calls from Java using invokedynamic using some tooling. SURE > WISH > I COULD EMIT INDY FROM JAVA :-D > * Profile Java-based Ruby core methods and find the worst poly/megamorphic > cases. Move them to Ruby. > Once code is in Ruby, I already have a POC to re-emit the bytecode on a > per-callsite basis. We should also be able to feed expected types into IR and > have it emit specialized versions for e.g. math. > Lots of stuff finally coming together, but Java is the biggest thing holding > me > back right now. > - Charlie Rémi -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To unsubscribe from this group and stop receiving emails from it, send an email to jvm-languages+unsubscr...@googlegroups.com. To post to this group, send email to jvm-languages@googlegroups.com. Visit this group at https://groups.google.com/group/jvm-languages. For more options, visit https://groups.google.com/d/optout.
