On Jul 6, 2011, at 10:49 PM, Tom Rodriguez wrote: > > On Jul 6, 2011, at 4:18 AM, Christian Thalinger wrote: > >> On Jul 5, 2011, at 6:39 PM, Charles Oliver Nutter wrote: >>> I'm not in position at this exact moment to report perf issues, but >>> Rémi's list would be a good start. I'll return to JRuby benchmarks and >>> start looking for specific bottlenecks. >> >> OK. >> >>> >>> As reported in some of my my previous emails, JRuby has several uses >>> of indy that are off by default, so it will be nice to start getting >>> them enabled. >> >> When I use -Xinvokedynamic.all=true with bench_string_ops.rb I get: >> >> InvokeDynamicSupport.java:710:in `fixnum_op_mul': >> java.lang.ClassCastException: org.jruby.RubyString cannot be cast to >> org.jruby.RubyFixnum >> >> I just saw a benchmark I haven't seen before: bench_avi_base64.rb >> >> Performance with indy is not very good: >> >> intelsdv07:~/mlvm/jruby$ jruby --server -Xcompile.invokedynamic=false >> bench/bench_avi_base64.rb >> 1.569000 0.000000 1.569000 ( 1.539000) >> 0.895000 0.000000 0.895000 ( 0.895000) >> 0.850000 0.000000 0.850000 ( 0.850000) >> 0.848000 0.000000 0.848000 ( 0.848000) >> 0.848000 0.000000 0.848000 ( 0.848000) >> >> intelsdv07:~/mlvm/jruby$ jruby --server bench/bench_avi_base64.rb >> 2.335000 0.000000 2.335000 ( 2.305000) >> 1.503000 0.000000 1.503000 ( 1.503000) >> 1.470000 0.000000 1.470000 ( 1.470000) >> 1.479000 0.000000 1.479000 ( 1.479000) >> 1.470000 0.000000 1.470000 ( 1.470000) >> >> The pattern I always see when I look at the inlining tree of a badly >> performing benchmark is this one: >> >> @ 9 >> org.jruby.runtime.invokedynamic.InvokeDynamicSupport::invocationFallback >> (197 bytes) inline (hot) > > I would think we don't want this inlined since it's the fallback path. Try > -XX:CompileCommand=dontinline,*,invocationFallback. Inlining it may cause us > to run up against other limits like the NodeInliningCutoff and > DesiredMethodLimit.
Ahh, right. This is inlined because of how we promote the invocation count of the call site into the method handle chain. Sorry, I forgot. -- Christian > > tom > >> @ 2 >> org.jruby.runtime.invokedynamic.InvokeDynamicSupport::pollAndGetClass (13 >> bytes) inline (hot) >> @ 1 >> org.jruby.runtime.ThreadContext::callThreadPoll (23 bytes) inline (hot) >> @ 19 >> org.jruby.runtime.ThreadContext::pollThreadEvents (9 bytes) inline (hot) >> @ 5 >> org.jruby.RubyThread::pollThreadEvents (13 bytes) inline (hot) >> @ 11 org.jruby.RubyModule::searchWithCache >> (68 bytes) already compiled into a medium method >> @ 19 >> org.jruby.runtime.invokedynamic.JRubyCallSite::callType (5 bytes) inline >> (hot) >> @ 25 >> org.jruby.runtime.invokedynamic.InvokeDynamicSupport::methodMissing (47 >> bytes) too big >> @ 34 >> org.jruby.runtime.invokedynamic.JRubyCallSite::callType (5 bytes) inline >> (hot) >> @ 43 >> org.jruby.runtime.invokedynamic.InvokeDynamicSupport::callMethodMissing (34 >> bytes) never executed >> ! @ 55 >> org.jruby.runtime.invokedynamic.InvokeDynamicSupport::getTarget (169 bytes) >> too big >> @ 109 >> org.jruby.runtime.invokedynamic.InvokeDynamicSupport::postProcess (315 >> bytes) too big >> @ 115 >> java.lang.invoke.MutableCallSite::getTarget (5 bytes) inline (hot) >> @ 128 >> java.lang.invoke.MutableCallSite::getTarget (5 bytes) inline (hot) >> @ 135 >> org.jruby.runtime.invokedynamic.InvokeDynamicSupport::createGWT (59 bytes) >> too big >> @ 138 >> java.lang.invoke.MutableCallSite::setTarget (15 bytes) executed < >> MinInliningThreshold times >> @ 156 >> org.jruby.runtime.invokedynamic.InvokeDynamicSupport::createGWT (11 bytes) >> never executed >> @ 159 >> java.lang.invoke.MutableCallSite::setTarget (15 bytes) executed < >> MinInliningThreshold times >> @ 94 >> org.jruby.runtime.invokedynamic.InvokeDynamicSupport::createFail (74 bytes) >> too big >> @ 100 >> java.lang.invoke.MutableCallSite::setTarget (15 bytes) executed < >> MinInliningThreshold times >> @ 190 >> java.lang.invoke.MethodHandle::invokeWithArguments (61 bytes) too big >> >> I remember we were talking about the createGWT. Can this go away? >> >> -- Christian >> >>> >>> On Tue, Jul 5, 2011 at 9:04 AM, Christian Thalinger >>> <christian.thalin...@oracle.com> wrote: >>>> Now that we are done with 7 I'm looking into performance issues we have. >>>> Are there any that you know of and would like to get fixed for 7u2? >>>> >>>> -- Christian >>>> _______________________________________________ >>>> 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 >> >> >> _______________________________________________ >> 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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
