Good news, bad news
Tom Rodriguez
tom.rodriguez at oracle.com
Mon May 23 15:20:45 PDT 2011
On May 23, 2011, at 2:50 PM, Charles Oliver Nutter wrote:
> Also, fwiw...after these two chunks in LogCompilation output, I see
> nothing else inlined into fib_ruby, including a monomorphic call path
> through PlusCallSite ending at RubyFixnum#op_plus (the integer +
> operation). That would also affect performance.
>
> I also do not see any indication *why* nothing inlines past this
> point. Usually it would say "too big" or something.
If there's no message then it wasn't even a candidate for inlining, either because the path was trimmed away by the optimizer or there wasn't enough information to bind the callsite to a particular method. It's probably the latter in this case. Actually my guess is that the selectAlternative machinery is what's screwing it up. That code gets emitted as:
(test ? a : b).invokeExact();
instead of
if (test) a.invokeExact(); else b.invokeExact();
Since the first one only uses a single call site we can't statically inline even if a and b are constants. The optimizer could do that optimization but it currently doesn't. Can you build the guard differently? We'll need to build a new call site optimization to deal with the selectAlternative logic.
tom
>
> I do see MinusCallSite inline earlier.
>
> - Charlie
>
> On Mon, May 23, 2011 at 4:47 PM, Charles Oliver Nutter
> <headius at headius.com> wrote:
>> The following chunk should be the invokedynamic call to fib, via a
>> GWT, an arg permuter, and perhaps one convert:
>>
>> @ 77 java.lang.invoke.MethodHandle::invokeExact (0 bytes)
>> @ 77 java.lang.invoke.MethodHandle::invokeExact (44 bytes)
>> @ 8 java.lang.invoke.MethodHandle::invokeExact (0 bytes)
>> @ 8 java.lang.invoke.MethodHandle::invokeExact (7 bytes)
>> @ 3 org.jruby.runtime.invokedynamic.InvokeDynamicSupport::test
>> (20 bytes)
>> @ 5 org.jruby.RubyBasicObject::getMetaClass (5 bytes)
>> @ 8 org.jruby.RubyModule::getCacheToken (5 bytes)
>> @ 23 java.lang.invoke.MethodHandle::invokeExact (0 bytes)
>> @ 23 java.lang.invoke.MethodHandle::invokeExact (67 bytes)
>> @ 1 java.lang.Boolean::valueOf (14 bytes)
>> @ 10 java.lang.invoke.MethodHandle::invokeExact (0 bytes)
>> @ 10 java.lang.invoke.MethodHandle::invokeExact (24 bytes)
>> @ 11 java.lang.Boolean::booleanValue (5 bytes)
>> @ 20 java.lang.invoke.MethodHandleImpl::selectAlternative (10 bytes)
>> @ 63 java.lang.invoke.MethodHandle::invokeExact (0 bytes)
>> @ 37 sun.invoke.util.ValueConversions::identity (2 bytes)
>>
>> This seems to only be the test logic; the actual fib invocation
>> doesn't appear to show up in the inlining graph at all. Am I right?
>>
>> I see two of these in the LogCompilation output and nothing else
>> around them. I'd expect to see them do the invocation of fib_ruby
>> somewhere in there. It's like the "success" branch of GWT is not even
>> being considered for inlining.
>>
>> - Charlie
>>
>> On Mon, May 23, 2011 at 4:41 PM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
>>> If there were to be a recursive inline in there, where would it occur? I can't tell from the names where in that inline tree where the recursive call occurs.
>>>
>>> tom
>>>
>>> On May 23, 2011, at 2:26 PM, Charles Oliver Nutter wrote:
>>>
>>>> fib_ruby LogCompilation inlining graph, showing that fib_ruby is not
>>>> inlined: https://gist.github.com/f2b665ad3c97ba622ebf
>>>>
>>>> Can anyone suggest other flags I can try to adjust to get things to
>>>> inline better?
>>>>
>>>> FWIW, the handle chain in question that's not inlining is pretty simple:
>>>>
>>>> * DMH pointing back at fib_ruby
>>>> * permute args
>>>> * GWT
>>>>
>>>> - Charlie
>>>>
>>>> On Mon, May 23, 2011 at 4:19 PM, Charles Oliver Nutter
>>>> <headius at headius.com> wrote:
>>>>> I'm working up a set of files that show JRuby compilation output, but
>>>>> I noticed a couple things that might be interesting right now.
>>>>>
>>>>> First off, fairly early in the assembly output for fib, I see this:
>>>>>
>>>>> 0x02876d1f: call 0x0282d0e0 ; OopMap{[96]=Oop [100]=Oop
>>>>> [28]=Oop [40]=Oop [48]=Oop off=644}
>>>>> ;*invokespecial invokeExact
>>>>> ; -
>>>>> java.lang.invoke.MethodHandle::invokeExact at 63
>>>>> ; -
>>>>> java.lang.invoke.MethodHandle::invokeExact at 23
>>>>> ; -
>>>>> bench.bench_fib_recursive::method__0$RUBY$fib_ruby at 51 (line 7)
>>>>> ; {optimized virtual_call}
>>>>>
>>>>> For fib, the only invokedynamic is the recursive call to fib, so that
>>>>> would indicate that fib_ruby is not inlining into itself at all here.
>>>>> And I can't see it inlining into itself anywhere in the assembly
>>>>> output.
>>>>>
>>>>> Later in the same output:
>>>>>
>>>>> 0x0287703f: call 0x0282dba0 ; OopMap{ebp=Oop off=1444}
>>>>> ;*checkcast
>>>>> ; -
>>>>> java.lang.invoke.MethodHandle::invokeExact at 40
>>>>> ; -
>>>>> bench.bench_fib_recursive::method__0$RUBY$fib_ruby at 82 (line 7)
>>>>> ; {runtime_call}
>>>>> 0x02877044: call 0x0105a9d0 ;*checkcast
>>>>> ; -
>>>>> java.lang.invoke.MethodHandle::invokeExact at 40
>>>>> ; -
>>>>> bench.bench_fib_recursive::method__0$RUBY$fib_ruby at 82 (line 7)
>>>>> ; {runtime_call}
>>>>>
>>>>> These appear repeatedly near the invokedynamic invocation above. If
>>>>> I'm reading this right, neither the recursive call nor logic involved
>>>>> in that particular handle is inlining. Am I right?
>>>>>
>>>>> Here's the complete assembly dump (i386) for the fib_ruby method:
>>>>> https://gist.github.com/987640
>>>>>
>>>>> In other news, MaxInlineSize=150 with InlineSmallCode=3000 does not
>>>>> appear to improve performance. I also tried bumping up
>>>>> MaxRecursiveInlineLevel and MaxInlineLevel with no effect.
>>>>>
>>>>> - Charlie
>>>>>
>>>> _______________________________________________
>>>> 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