I also need to say this: PUT ME TO WORK :) I'm very eager to start showing off invokedynamic and make it pervasive throughout JRuby (or as pervasive as possible while still supporting Java 6). Tell me what I need to do to help!
- Charlie On Fri, Feb 18, 2011 at 2:06 PM, Charles Oliver Nutter <head...@headius.com> wrote: > On Fri, Feb 18, 2011 at 7:19 AM, Christian Thalinger > <christian.thalin...@oracle.com> wrote: >> What I can tell so far is that setting rubyDirect=true inlines a whole lot >> more stuff than without. I looks like it wants to inline all recursive >> calls of fib_ruby into a single method, which doesn't work very well, >> hitting two limits: NodeCountInliningCutoff and DesiredMethodLimit. >> >> I tried to bump these limits but that is a dead end for the compiler since >> at one point it skips the compile because it gets too many nodes: >> >> 43 COMPILE SKIPPED: out of nodes parsing method (not retryable) >> >> I don't know why it wants to inline all these recursive calls. Is that >> something JRuby tries to do? > > Nope, we're not doing anything special there. Here's the basic layout > (review for you perhaps): > > Prior to this work, invokedynamic connected the call sites up to our > existing DynamicMethod objects via the "call" method. In most cases, > those objects were a unique class per method, to allow things to > inline, but ultimately they added one or two intermediate frames to > every indy call path. You can see that in my previous email. > > In between then and now, I worked on "dynopt". Dynopt in JRuby > basically takes the last-seen method at a call site while interpreting > and inserts a guard, direct call to that method (*really* > direct...invokevirtual or invokestatic), and fallback to the old call > site logic. This worked for native core methods with fixed arities and > no closure, a few "intrinsics", self-recursing calls (fib, tak), and > Float and Fixnum dispatches with or without a boxed argument. It also > inlined directly any trivial leaf methods (constant return value, > simple state lookups, etc). This work improved the performance of > small benchmarks substantially, and the largest part of that > improvement came from being able to directly make recursive calls. > > The new indy work in JRuby basically takes the direct-binding part of > that work and uses it to patch invokedynamic all the way through, > skipping DynamicMethod. It works for the cases I listed in my email to > Rémi: basically any fixed-arity, no-block, core class or Ruby-to-Ruby > calls. Next I was going to explore patching Ruby to Java calls all the > way through as well. > > At *best* this logic does nothing more than remove as many > intermediate frames between the caller and target. We do no manual > inlining (except for the trivial leaf cases), and are simply > connecting A with B. > > On the one hand I'm thrilled to see that a lot of stuff is inlining. > With only a tiny amount of work, Ruby calls can inline into Ruby > calls, with very little intervening overhead. > > But on the other hand, I'm not sure what I should expect to see from a > performance perspective. "dynopt" inlines Ruby into Ruby as well, at > the cost of a lot of bytecode in each Ruby method body, eating up that > precious budget. I would have expected the Ruby-to-Ruby inlining via > invokedynamic to perform as well or better than dynopt. > > I'm not grousing about performance, mind you :) I think it's just > awesome how cleanly this is working so far with not a whole lot of > effort. I'm champing at the bit to make all of JRuby > invokedynamic-aware. But obviously the perf is not as good as we'd > expect it, and I'm standing by to help provide information or > experiment to improve it. > > FWIW, you can specify jruby.compile.dynopt=true to turn on dynopt for > benchmarks, if you'd like to compare with indy. It can take longer to > ramp up, since it forces 100% JIT (no force-compiling the target > script immediately), which is then subject to a hard 50-invocation > threshold. > > - Charlie > _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
