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