RFR: 8234863: Increase default value of MaxInlineLevel

Nils Eliasson nils.eliasson at oracle.com
Mon Dec 9 15:20:46 UTC 2019


Hi,

For the record - I agree with Claes point. There are a lot of other 
things that will be nice to evaluate in a later release, but given that 
the data for this change looks good - I think we show go ahead.

Reviewed,

Nils


On 2019-12-09 13:44, Claes Redestad wrote:
> Hi,
>
> Nils raised this issue in the bug, and while I think it's a fair point I
> think it's orthogonal to whether or not we can/should tune the default
> here and now. I think the data we have speaks in favor of doing this
> tuning for JDK 14, and then re-evaluate with more real-world data for
> JDK 15, possibly dialing back the C1 defaults.
>
> When implementing such flags we can also evaluate if C1 should be even
> more conservative than it is today. It's also worth thinking about
> whether or not we should introduce different settings for C1 level 1, 2
> and 3..
>
> /Claes
>
> On 2019-12-09 12:16, Doerr, Martin wrote:
>> Hi,
>>
>> I think tuning inlining makes sense for C2.
>>
>> The problem I see is that C1 uses the same inlining flags.
>> C1 doesn't have the concept of uncommon traps so it compiles all paths.
>> That's why I think this change is only good for C2.
>>
>> So I suggest separating C1 inlining flags before tuning them for C2 
>> like in the example below (note that new flags require CSR).
>> Feedback for this idea is welcome.
>>
>> Best regards,
>> Martin
>>
>>
>>
>> diff -r 45fceff98bb5 src/hotspot/share/c1/c1_globals.hpp
>> --- a/src/hotspot/share/c1/c1_globals.hpp       Mon Dec 09 10:26:41 
>> 2019 +0100
>> +++ b/src/hotspot/share/c1/c1_globals.hpp       Mon Dec 09 12:08:37 
>> 2019 +0100
>> @@ -174,6 +174,12 @@
>>     develop_pd(bool, 
>> RoundFPResults,                                          \
>>             "Indicates whether rounding is needed for floating point 
>> results")\
>> \
>> +  product(intx, C1MaxInlineSize, 
>> 35,                                        \
>> +          "The maximum bytecode size of a method to be inlined by 
>> C1")      \
>> +  product(intx, C1MaxInlineLevel, 
>> 9,                                        \
>> +          "The maximum number of nested calls that are inlined by 
>> C1")      \
>> +  product(intx, C1MaxRecursiveInlineLevel, 
>> 1,                               \
>> +          "maximum number of nested recursive calls that are 
>> inlined")      \
>>     develop(intx, NestedInliningSizeRatio, 
>> 90,                                \
>>             "Percentage of prev. allowed inline size in recursive 
>> inlining")  \
>>             range(0, 
>> 100)                                                     \
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: hotspot-compiler-dev <hotspot-compiler-dev-
>>> bounces at openjdk.java.net> On Behalf Of Claes Redestad
>>> Sent: Montag, 9. Dezember 2019 11:15
>>> To: Vladimir Kozlov <vladimir.kozlov at oracle.com>; hotspot compiler
>>> <hotspot-compiler-dev at openjdk.java.net>
>>> Subject: Re: RFR: 8234863: Increase default value of MaxInlineLevel
>>>
>>> Thanks for the review!
>>>
>>> /Claes
>>>
>>> On 2019-12-09 01:52, Vladimir Kozlov wrote:
>>>> Nice finding! Good.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 12/8/19 1:44 PM, Claes Redestad wrote:
>>>>> Hi,
>>>>>
>>>>> increasing MaxInlineLevel can substantially improve performance in 
>>>>> some
>>>>> benchmarks[1], and has been reported to help applications implemented
>>> in
>>>>> scala in particular.
>>>>>
>>>>> There is always some risk of regressions when tweaking the default
>>>>> inlining settings. I've done a number of experiments to ascertain 
>>>>> that
>>>>> the effect of increasing this on a wide array of benchmarks. With 
>>>>> 15 all
>>>>> benchmarks tested are show either neutral or positive results, 
>>>>> with no
>>>>> observed regression w.r.t. compilation speed or code cache usage.
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~redestad/8234863/open.00/
>>>>>
>>>>> Thanks!
>>>>>
>>>>> /Claes
>>>>>
>>>>> [1] One http://renaissance.dev sub-benchmark improve by almost 3x
>>> with
>>>>> an increase from 9 to 15.


More information about the hotspot-compiler-dev mailing list