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

[Xin Liu]

On Mon, 26 Feb 2024 22:05:47 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> The check was added as part of JDK-4292742 fix and special attention was paid there to avoid excessive trapping behavior. How much the removal worsens the situation?

I also would like to learn the downsides. 

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.

I read the bug description of 'JDK-4292742'. It's something about inconsistent stacktraces between -client and -server. I can't find the patch. I guess C2 uses 'is_mature()' to skip NPE, RCE, DIV0, and casts? Are those function calls? if yes, I think baz() is in the same bucket of them. The only difference is that we want to inline baz() whereas John wants to avoid NPE, RCE etc.

> Personally, I'd be more comfortable with a more nuanced fix. Inlining a method with immature profile does look like a source of excessive recompilations in large applications.

I agree. I wonder if we have better approach on this. JRuby has to translate all operations of a Fixnum object.  Some of them are corner cases, but those a handful of rare methods prevent escape analysis from marking 'receiver' NonEscape. 
 
I don't think '_count field of ciCallProfile = -1' is correct for an immature method. it forces c2 to outline a call. C2 should make judgement based on the information HotSpot has collected. The real frequency is > than `MinInlineFrequencyRatio`. 

One idea I came up is that we add the immature method 'bar' to the dependency list of method foo(). Once c1 collects enough information, we recompile method foo() and see if we get better revision. I gave up because it's complex. 

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

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

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