RFR: 8234863: Increase default value of MaxInlineLevel

[Kirk Pepperdine]

+1 to what Charlie has said. Additionally we’ve been exploring EA with an eye on improving it’s ability to catch and eliminate transients. So far the work is showing lots of promise.

Kind regards,
Kirk


> On Dec 9, 2019, at 10:31 PM, Charles Oliver Nutter <headius at headius.com> wrote:
> 
> This gets a big +1 for me, but honestly even better would be eliminating
> the hard inline level limit altogether in favor of other metrics (inlined
> code size, optimized node count, incremental inlining). Ignoring that for
> the moment...
> 
> Anecdotally, I can say that there are many code paths in JRuby that don't
> inline fully *solely* because of this limit. For example, there are objects
> in the numeric tower that out of compatibility necessity have constructor
> paths that get dangerously close to 9 levels deep:
> 
> calling code-> Fixnum factory -> Fixnum constructor -> Integer -> Numeric
> -> Object -> BasicObject -> j.l.Object
> 
> ...and that would just inline into the first level of Ruby code. The last
> five levels here are mostly just "super()" calls. Ideally we would want to
> have a few levels of Ruby code inlining together too.
> 
> If this path doesn't inline, we've got no chance for escape analysis and
> other optimizations to reduce the transient numeric objects.
> 
> A question relating to JRuby: how does the inline level interact with
> MethodHandle/LambdaForm @ForceInline? Does that get around it? ALWAYS?
> Clearly we see most of our invokedynamic call sites inline, but I have
> little understanding of the actual cost of the five to 10 to 20 levels of
> LFs between an indy site and the eventual target.
> 
> In any case... +1, inline all the things.
> 
> - Charlie
> 
> On Sun, Dec 8, 2019 at 3:42 PM Claes Redestad <claes.redestad at oracle.com>
> 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.
>>