where are our performance bottlenecks?

Christian Thalinger christian.thalinger at oracle.com
Wed Jul 6 23:52:52 PDT 2011


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.thalinger at 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 at openjdk.java.net
>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>> 
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> 
>> 
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev




More information about the mlvm-dev mailing list