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? 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! > 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
