RFR: 8234863: Increase default value of MaxInlineLevel

[John Rose]

On Dec 12, 2019, at 6:47 PM, Jason Zaugg <jzaugg at gmail.com> wrote:
> 
> I could spend some time to clean up the patch. However, I would need
> signficant guidance
> to extend it to John's suggestion to admit type adaptations / constant
> loads / known
> cheap methods etc. Would this more thorough analysis it suit a C2-only
> analysis
> performed on an IR instead?

C2 doesn’t convert a method into IR until it has made the inlining
decision about it.  It would be a much deeper change to switch that around.

However, ciMethod::get_flow_analysis activates a general purpose
bytecode-based flow analysis which could easily be adjusted to add
the necessary metrics.  Since it is already run from the inline logic,
this wouldn’t be a new pass.

(There’s also ciMethod::get_bcea which performs a much more specialized
escape analysis on methods, after they fail to inline.  I don’t think that’s
the place for the new metrics.)

> Is the set of cheap methods defined with an annotation,
> a list of owner/name/descriptors or some other means?

Something along the lines of ciMethod::is_boxing_method
will work.  In other words, a hardwired white list.
Annotations will probably play a role.  For example, most of the JIT’s
“magically known methods” sport @HotSpotIntrinsicCandidate,
and are registered in vmIntrinsics.hpp.  The annotations @ForceInline
and @DontInline are another example.  We could have a @TinyInline
annotation, meaning “don’t expect this thing to expand much if you
inline it”, or we could try to detect such things using further metrics,
again in TypeFlow.

> What is the testing strategy?

The usual:  Mainly functional and performance regressions.
Some manual and white box testing to make sure the expected sorts of
inline chains don’t suddenly stop inlining.

> It would likely be more efficient for someone with the experience in the
> code base implement themselves rather than shepherd me through it :)

I’m intrigued that you are interested in this, and I encourage you to consider
pulling on this string some more.  I’ll help you pull if you want.

I think this is doable, to a degree, as a starter project, to install new parameters
and do initial exploration of their settings.  Actually dialing in the settings
and testing them across a range of workloads is a very specialized job, which
few of us are good at, but if the optimization seems to pan out we can find
the necessary kind of expert.

Your first step, should you choose to accept this mission, would be to join
the community.  Your name should be on http://openjdk.java.net/census.
See http://openjdk.java.net/contribute/.

— John