RFR: 8234863: Increase default value of MaxInlineLevel

[Vladimir Ivanov]

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

Also, I'd like to add that it's fine to fix it in incrementally: start 
with something simple and reliable, and then explore more complex 
extensions on top of it.

I don't think it's necessary to  bytecode analysis too far. I agree with 
you that some point it becomes simpler to just parse the method and 
observe the effects than trying to derive them directly from bytecode.

(I fully agree that it requires significant effort to enable IR-based 
analysis in C2. But also there are ways to workaround that and cache the 
analysis results across compilations: gather data during stand-alone 
compilation and then reuse it when doing inlining.)

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

FTR part of @LambdaForm.Compiled semantics is equivalent to @TinyInline.

Best regards,
Vladimir Ivanov

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