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. 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 >> <[email protected]> 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 >>> [email protected] >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> >> _______________________________________________ >> mlvm-dev mailing list >> [email protected] >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > > _______________________________________________ > mlvm-dev mailing list > [email protected] > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
