RFR: 8234863: Increase default value of MaxInlineLevel

[John Rose]

On Dec 13, 2019, at 2:44 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
> 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.

+1

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

The reason I point out ciTypeFlow is that it already parses the bytecodes.
It does this mainly to build a CFG, but given the framework it is easy to add
other small chores.  I see counting instructions, by kind, as a small chore.

Another place where such counting could be added is the construction of
ciMethodData.  It seems reasonable to me to associate static metrics with
a method at the same time as setting up dynamic metric collection.

Jason noted JDK-8056071 as an example of bytecode instruction scanning.
The fix in that bug is to extend the specialized recognizers of bytecodes.*pp
to detect “tiny methods”.  If I had to choose between adding more of those
recognizers and adding extra chores to the ciMethodData or ciTypeFlow passes,
I’d prefer to do the latter, because the instruction classification is already
written and debugged for the full passes.

The recognizers in bytecodes.*pp always bothered me a little, that they are
thrown off by tiny variations in the code.  A counting technique that looks
at all instructions is more robust, since it can more easily discount simple
instructions like data movement and constant materialization.

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

I’d like to mine out more of the potential in adding those “extra chores”
to existing passes before doing IR caching.  In fact, I see IR caching as
one of those big investments that we should do in C2’s Java-based
successor.  Caching is a near cousin to serialization, and that is much
more easily done on reflective Java data than on C++ data.  (Or maybe
I missed your point?)  The C2 IR is not garbage collected, but rather
thread-confined and deleted wholesale after each compilation task.
Sharing across compilation tasks is a hard problem, as we found when
we built the CI.

— John