On May 25, 2011, at 9:39 PM, Charles Oliver Nutter wrote: > On Wed, May 25, 2011 at 5:12 PM, Tom Rodriguez <tom.rodrig...@oracle.com> > wrote: >> I've got the bimorphic method handle inline working. I was doing something >> stupid at the beginning which is why it wasn't as easy as I expected to be >> and then I encountered a stupid API which wasted a little more time. I was >> able to leverage the existing invokedynamic call site cache code generation >> and just generate a different guard. Ignoring the flag soup below, the >> first is without invokedynamic, second is with and third is with bimorphic >> inline for selectAlternative. > > Here's a dumb question...couldn't the bimorphic logic have simply been > generated the second way you indicated, rather than the (x ? a : > b).whatever form?
That pattern is something the java.lang.invoke machinery is generating as far I can tell. selectAlternative does something like: (test ? a : b).invokeExact() and I'm converting it to something like: c = (test ? a : b); if (c == a) a.invokeExact(); else b.invokeExact(); The optimizer turns this into: if (test) a.invokeExact(); else b.invokeExact(); but test is some ugly goo because of boxing. It's relatively easy to get the optimizer to fold away the boxing for boolean but sadly it doesn't help the performance at all. Additionally that ends up touching a fair amount of common code which makes it a little more risky for 7. One oddity I've noticed is that what we're ending up with lots of checkcasts to IRubyObject but the optimizer doesn't eliminate redundant ones, probably because it's a checkcast to an interface. > > Great to hear this is in! I'll look for an MLVM patch and until then > see if I can figure out why the "classic" GWT logic isn't as fast as > it was a couple weeks ago. IF I'm feeling saucy I may try to pull MLVM > + bsd-port from two weeks ago (or find a macosx port build from that > timeframe) to compare assembly output. Perhaps illustrative for us > all! I think that would be informative. tom > >> The changes are at http://javaweb.sfbay.sun.com/~never/webrev/bim. Maybe >> John can put together an mlvm patch for it. I'm not quite sure how to do so. >> >> There are still some minor improvements that can be made. The test part >> ends up looking like: >> >> if ((test ? Boolean.TRUE : Boolean.FALSE).value()) >> >> We need to treat more of those values as constants and split the loads up to >> fold it away. > > I'm keen to have a look at the assembly resulting from the bimorphic > inlining and see if there's any way to improve it further. My test > could potentially be improved too. > > I'm also pondering ways I can go mostly guard-free for certain core > JRuby types, possibly reducing the guard to an exact type check. > There's definitely runway both on your end and my end. > > - 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
