RFR: 8325681: C2 inliner rejects to inline a deeper callee because the methoddata of caller is immature. [v2]

[Vladimir Ivanov]

On Tue, 27 Feb 2024 06:41:43 GMT, Xin Liu <xliu at openjdk.org> wrote:

> You mean method_data()->is_mature() was introduced 20 years ago? I didn't capture this. git blame can only trace back to '8153779ad32d1e8ddd37ced826c76c7aafc61894', or "Initial load" in 2007.

It predates OpenJDK and unfortunately the repository doesn't have any history left from that period. 

> May I know more about 'excessive recompilation'? what's your definition of it?
why does using immature methoddata lead to excessive recompilation?

C2 heavily relies on profiling when performing speculative optimizations. The assumption is the profile is accurate enough to make all the speculations a net win. Optimizing a large enough application consists of numerous individual guesses and some of the predictions routinely fail at runtime causing expensive to recover situations (e.g., "just" an uncommon trap or a signal caused by an implicit exception followed by full reprofile-recompile cycle). If profile data is of a poor quality, it can mislead the compiler to make suboptimal choices and worsen the situation.  

So, C2 heuristics are tuned to let the profile mature assuming the data becomes more representative over time. (Relevant comment in [methodData.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/methodData.hpp#L41).)

Based on the synopsis, the motivation for the fix is to help C2 EA pass. Indeed, there are many situations when a full-blown call in generated code severely affects the quality of optimizations. On the other hand, it a method is inlined prematurely, it may cause a net performance loss as well. For example, when compiled code is invalidated shortly after the compilation, the resources spent on the compilation are wasted  and it slows down application warmup.

There were some discussions in the past about EA-aware inlining heuristics. Unfortunately, not much progress has been done on that front yet. Partly, because it's notoriously hard and risky to incrementally improve inlining heuristics: they have pervasive effects, so even trivial changes easily cause numerous improvements and regressions across a wide set of applications.

Speaking of your particular case, as an idea: maybe a static analysis of the callee method may give enough confidence that profile quality doesn't matter there, so it's safe to inline when there are clear benefits for EA? C2 EA already perform some amount of analysis to detect when objects arg-escape (see  [BCEscapeAnalyzer](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/ci/bcEscapeAnalyzer.hpp).) Ideally, that would also imply enhancing EA with a post-parse inlining pass.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17957#discussion_r1504830524