C2: Advantage of parse time inlining

[Vitaly Davidovich]

I should also add that I see how inlining without taking call freq into
account could lead to faster time to peak performance for methods that
eventually get hot anyway but aren't at parse time.  Peak perf will be the
same if the method is too big for parse inlining but eventually gets
compiled due to reaching hotness.  Is that about right?

sent from my phone
On May 14, 2015 12:57 PM, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:

> Vladimir,
>
> I'm comparing MaxInlineSize (35) with FreqInlineSize (325).  AFAIU,
> MaxInlineSize drives which methods are inlined at parse time by C2, whereas
> FreqInlineSize is the threshold for "late" (or what do you guys call
> inlining after parsing?) inlining.  Most of the inlining discussions (or
> worries, rather) seem to focus around the MaxInlineSize value, and not
> FreqInlineSize, even if the target method will get hot.
>
> Usually, people care about 35 (= MaxInlineSize), because for methods up to
>> MaxInlineSize their call frequency is ignored. So, fewer chances to end up
>> with non-inlined call.
>
>
> Ok, so for hot methods then MaxInlineSize isn't really a concern, and
> FreqInlineSize would be the threshold to worry about (for C2 compiler)
> then? Why are people worried about inlining in cold paths then?
>
> Thanks Vladimir
>
> On Thu, May 14, 2015 at 12:36 PM, Vladimir Ivanov <
> vladimir.x.ivanov at oracle.com> wrote:
>
>> Vitaly,
>>
>> Can you elaborate your question a bit? What do you compare parse-time
>> inlining with? Mentioning of С1 & profile pollution in this context
>> confuses me.
>>
>> Usually, people care about 35 (= MaxInlineSize), because for methods up
>> to MaxInlineSize their call frequency is ignored. So, fewer chances to end
>> up with non-inlined call.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 5/14/15 7:09 PM, Vitaly Davidovich wrote:
>>
>>> Any pointers? Sorry to bug you guys, but just want to make sure I
>>> understand this point as I see quite a bit of discussion on core-libs
>>> and elsewhere where people are worrying about the 35 bytecode size
>>> threshold for parse inlining.
>>>
>>> On Wed, May 13, 2015 at 3:36 PM, Vitaly Davidovich <vitalyd at gmail.com
>>> <mailto:vitalyd at gmail.com>> wrote:
>>>
>>>     Hi guys,
>>>
>>>     Could someone please explain the advantage, if any, of parse time
>>>     inlining in C2? Given that FreqInlineSize is quite large by default,
>>>     most hot methods will get inlined anyway (well, ones that can be for
>>>     other reasons).  What is the advantage of parse time inlining?
>>>
>>>     Is it quicker time to peak performance if C1 is reached first?
>>>
>>>     Does it ensure that a method is inlined whereas it may not be if
>>>     it's already compiled into a medium/large method otherwise?
>>>
>>>     Is parse time inlining not susceptible to profile pollution? I
>>>     suspect it is since the interpreter has already profiled the inlinee
>>>     either way, but wanted to check.
>>>
>>>     Anything else I'm not thinking about?
>>>
>>>     Thanks
>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150514/32f3bbc1/attachment.html>