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@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
