Good news, bad news
Charles Oliver Nutter
headius at headius.com
Mon May 23 15:27:08 PDT 2011
On Mon, May 23, 2011 at 5:20 PM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
>
> On May 23, 2011, at 2:50 PM, Charles Oliver Nutter wrote:
>> 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.
Good to know I'm reading this output right :) Is there another logging
flag that will log these situations too? I'd like to have that not
just for invokedynamic opto.
> 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.
Is this a question for me? If so...
Build the guard differently as in don't use
MethodHandles.guardWithTest? I probably could, but it would require
inserting "normal" Java code into the call path, which should in
theory be megamorphic (since all invokedynamic everywhere will go
through that same piece of code). Something like:
IRubyObject myGuardWithTest(MethodHandle dmh, args...) {
if (test(args) {
return dmh.invokeExact(args);
} else {
inline cache
}
}
I'd *love* for intermediate static Java snippits like this to inline
straight through, even if invokeExact would be megamorphic under
normal circumstances...but I don't think that's the case right now,
right?
- Charlie
>
> 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
>
> _______________________________________________
> 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