RFR: 8325681: C2 inliner rejects to inline a deeper callee because the methoddata of caller is immature. [v2]
Xin Liu
xliu at openjdk.org
Tue Mar 5 05:14:45 UTC 2024
On Tue, 27 Feb 2024 19:42:25 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:
>>> 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.
>>
>> Indeed, that does look excessive. As another idea: utilize frequencies, but not type profiles at call sites with immature profiles. But then the next question is how representative the profile data at callee side then...
>
> Actually, there's a similar problematic scenario, now at allocation site: a local allocation followed by a long running loop.
>
> A a = factoryA::make(...); // new A(...)
> for (int i = 0; i < large_count; i++) {
> // ... a is eligible for scalarization ...
> }
>
> Inlining `make` method is a prerequisite to scalarize `a`, but profiling data is so scarce and hard-to-gather (a sample per long-running loop), so it's impractical to wait until profiling is over. It's straightforward to prove that `make` frequency is 100% of total executions (since it dominates the loop), but absolute counts don't make it evident.
I have 2 thoughts on this problem.
1) ArgEscape won't be a problem if we have stack-allocation. Even under profiling, it won't hurt.
2) for your case and mine, we can leverage iterative EA, BCEscapeAnalyzer and late-inlining.
After EA analysis, C2 can have a map. An ArgEscape object maps to a list of function calls. As long as compiler still has budget, C2 can do late-inline for the cheapest obj. it will convert an Argscape to NonEscape.
I feel only 1 is a general solution. For 2), it's hard to have a cost model. In your example, we probably need to inline 100 bytecodes(factorA::make) to make 'a' NonEscape. Bigger code may lose to one fast allocation.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/17957#discussion_r1512142246
More information about the hotspot-compiler-dev
mailing list