RFR: 8234863: Increase default value of MaxInlineLevel

[Charles Oliver Nutter]

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.
>