RFR: 8234863: Increase default value of MaxInlineLevel

[John Rose]

On Dec 17, 2019, at 5:15 AM, Jason Zaugg <jzaugg at gmail.com> wrote:
> 
> Thanks for the encouragement. I've submitted an OCA and will work on a
> patch.

Very good!

> I'm past some initial tooling issues -- I can build an image and run jtreg.. I've
> added [1] a simple version of the analysis to the existing the flow analysis and
> hooked this into InlineTree::try_to_inline. I've added a new test in the same
> manner as inlining/InlineAccessors.java.

This is on the right track.  Try to find the simple wins, of course.
And please see my previous messing in this thread to Vladimir.

One place to consider piggy-backing the counting techniques
in ciTypeFlow is in apply_one_bytecode.  (Counts should
only be accumulated the first time through each block.)
The tricky part would be factoring the code so that the
counting logic would not obscure the type flowing logic,
but I think this is doable.  The reason I like this possibility
is that ciTypeFlow ignores some unreached instructions.

That potentially covers some cases of assertion code which
is turned off, and exception processing code which has never
(yet) been called, and would force a deoptimization if it
were called into service.  These cases are notorious for
harming inlining.  If we could say “this is a tiny method,
except for assertion and exception processing code that
never runs”, we could build a more robust inlining policy.

Something similar might be doable with MethodData,
earlier in execution; I haven’t thought it through.  Perhaps
MethodData could associate instruction kind counts with
reachable points in the bytecode, which other clients,
including ciTypeFlow, could make use of.  I think ciTF
is a better cut point.

> I'll flesh this out and report back after Christmas.

Nice; let’s see where it goes.  Despite all my musings about
abstract interpretation, do start small.  Even small is hard.

— John