Good news, bad news

[Charles Oliver Nutter]

On Wed, May 25, 2011 at 5:12 PM, Tom Rodriguez <tom.rodriguez at 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