Adjust inliner use of profiled fanin data #21001
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mpirvu
force-pushed
the
inline-fanin-fix
branch
from
621c1a8 to
6f4ef00
Compare
|
jenkins test sanity all jdk21 |
|
zlinux failed one test j9vmtest_4. 50x grinder here: https://openj9-jenkins.osuosl.org/job/Grinder/4076/ passed |
The inliner uses some heuristics that tries to avoid the inlining of large callees that have already been compiled. What constitutes a large method is determined in a routine called `isLargeCompileMethod()`. If the callee is in a large frequency block, then we always want to inline that callee. If the callee is in a medium or low frequency block, then we look at callee size and at the fanin info (how many methods call this callee). For low frequency blocks we are more conservative with inlining than with medium frequency blocks. The existing code contained a bug in that, if there was no fanin info for a callee in a low/medium frequency block, we would always inline the callee, regardless of its size. This commit fixes this problem and considers the size of the callee first and then the fanin info. If there is no fanin info, then the size of the callee is the only criterion. Signed-off-by: Marius Pirvu <[email protected]>
mpirvu
force-pushed
the
inline-fanin-fix
branch
from
6f4ef00 to
c58b321
Compare
|
Rebased to incorporate the latest fanin change from #21004 |
|
jenkins test sanity all jdk21 |
|
All tests have passed, except on AIX. On AIX one of the 3 testlists has experienced an infra problem which I have seen before: It's already tracked here: #19962 |
|
Attn @vijaysun-omr |
vijaysun-omr
approved these changes
Jan 27, 2025
|
I agree with the logic behind this change. Test have also passed. Merging. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The inliner uses some heuristics that tries to avoid the inlining of large callees that have already been compiled. What constitutes a large method is determined in a routine called
isLargeCompileMethod().If the callee is in a large frequency block, then we always want to inline that callee.
If the callee is in a medium or low frequency block, then we look at callee size and at the fanin info (how many methods call this callee). For low frequency blocks we are more conservative with inlining than with medium frequency blocks. The existing code contained a bug in that, if there was no fanin info for a callee in a low frequency block, we would always inline the callee, regardless of its size.
This commit fixes this problem and considers the size of the callee first and then the fanin info. If there is no fanin info, then the size of the callee is the only criterion.