Good news, bad news

[Tom Rodriguez]

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.

( setenv _JAVA_OPTIONS "-XX:-PrintCompilation -Xbootclasspath/p:/export/ws/twisti/meth.jar -XX:+UseNewCode -Xbatch -XX:-UseNewCode2 -XX:-LogCompilation -XX:-PrintInlining" ; setenv JAVA_HOME /export/ws/indy/i586/jdk1.7.0 ; ./bin/jruby --server -Xcompile.invokedynamic=false bench/bench_fib_recursive.rb 5 35 )                                                                                                                     
  2.006000   0.000000   2.006000 (  1.856000)
  1.391000   0.000000   1.391000 (  1.391000)
  1.386000   0.000000   1.386000 (  1.386000)
  1.386000   0.000000   1.386000 (  1.386000)
  1.385000   0.000000   1.385000 (  1.385000)

( setenv _JAVA_OPTIONS "-XX:-PrintCompilation -Xbootclasspath/p:/export/ws/twisti/meth.jar -XX:+UseNewCode -Xbatch -XX:-UseNewCode2 -XX:-LogCompilation -XX:-PrintInlining" ; setenv JAVA_HOME /export/ws/indy/i586/jdk1.7.0 ; ./bin/jruby --server -Xcompile.invokedynamic=true bench/bench_fib_recursive.rb 5 35 )
  4.235000   0.000000   4.235000 (  4.086000)
  3.689000   0.000000   3.689000 (  3.689000)
  3.687000   0.000000   3.687000 (  3.688000)
  3.680000   0.000000   3.680000 (  3.680000)
  3.680000   0.000000   3.680000 (  3.680000)

( setenv _JAVA_OPTIONS "-XX:-PrintCompilation -Xbootclasspath/p:/export/ws/twisti/meth.jar -XX:+UseNewCode -Xbatch -XX:+UseNewCode2 -XX:-LogCompilation -XX:-PrintInlining" ; setenv JAVA_HOME /export/ws/indy/i586/jdk1.7.0 ; ./bin/jruby --server -Xcompile.invokedynamic=true bench/bench_fib_recursive.rb 5 35 )Picked up 
  2.103000   0.000000   2.103000 (  1.950000)
  1.281000   0.000000   1.281000 (  1.281000)
  1.275000   0.000000   1.275000 (  1.274000)
  1.279000   0.000000   1.279000 (  1.279000)
  1.288000   0.000000   1.288000 (  1.288000)

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.

tom

On May 25, 2011, at 12:14 PM, John Rose wrote:

> On May 25, 2011, at 9:31 AM, Charles Oliver Nutter wrote:
> 
>> Build in progress! I'll let you know how it goes. How low is low in "low arity"?
> 
> About 0-9.
> 
> Let's find the next bottleneck!
> 
> -- John
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev