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.rodrig...@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
>> <head...@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@63
>>> ; -
>>> java.lang.invoke.MethodHandle::invokeExact@23
>>> ; -
>>> bench.bench_fib_recursive::method__0$RUBY$fib_ruby@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@40
>>> ; -
>>> bench.bench_fib_recursive::method__0$RUBY$fib_ruby@82 (line 7)
>>> ; {runtime_call}
>>> 0x02877044: call 0x0105a9d0 ;*checkcast
>>> ; -
>>> java.lang.invoke.MethodHandle::invokeExact@40
>>> ; -
>>> bench.bench_fib_recursive::method__0$RUBY$fib_ruby@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@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
