x86: refine iTable iteration heuristic after lastITable cache check#23640
Merged
0xdaryl merged 1 commit intoeclipse-openj9:masterfrom Apr 3, 2026
Merged
x86: refine iTable iteration heuristic after lastITable cache check#236400xdaryl merged 1 commit intoeclipse-openj9:masterfrom
0xdaryl merged 1 commit intoeclipse-openj9:masterfrom
Conversation
Contributor
Author
|
@0xdaryl May I ask you to review this change? Thank you! |
0xdaryl
reviewed
Apr 2, 2026
Contributor
0xdaryl
left a comment
0xdaryl
left a comment
There was a problem hiding this comment.
Logic seems fine to me. My only comments are on the comments.
Update determineNumOfITableIterations() to use a more nuanced heuristic when choosing how many iTable entries to probe after a failed lastITable cache check. Previously, the heuristic examined sampled implementers of the declaring interface, tracked only the maximum number of implemented interfaces, and always capped the returned iteration count at MAX_ITABLE_ITERATIONS. This change extends the analysis to also track: - the total number of interfaces across sampled implementers - whether all sampled implementers have the same interface count The new policy is: - return the exact interface count when there is only one implementer - return the exact interface count when all sampled implementers are uniform - fall back to MIN_ITABLE_ITERATIONS when the average interface count is high - otherwise retain the original capped behavior This preserves the original default/fallback behavior while allowing more accurate iteration counts in predictable implementer shapes, potentially avoiding unnecessary fallback to the lookup snippet. Signed-off-by: Annabelle Huo <a7eh1ogh@gmail.com>
a7ehuo
force-pushed
the
tune-itable-iterations-2
branch
from
045e59e to
69511ad
Compare
Contributor
|
Jenkins test sanity xlinux,win,osx jdk17 |
Contributor
|
x Linux failure is #13875 |
Contributor
|
Windows JDK17 failure is #22758 |
Contributor
|
fyi @zl-wang @rmnattas @knn-k @r30shah @ehsankianifar for thinking if this is something to consider for your platform/implementation |
Contributor
|
Windows OpenJDK failure is also #13875 |
0xdaryl
approved these changes
Apr 3, 2026
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Update determineNumOfITableIterations() to use a more nuanced heuristic when choosing how many iTable entries to probe after a failed lastITable cache check.
Previously, the heuristic examined sampled implementers of the declaring interface, tracked only the maximum number of implemented interfaces, and always capped the returned iteration count at MAX_ITABLE_ITERATIONS. This change extends the analysis to also track:
The new policy is:
This preserves the original default/fallback behavior while allowing more accurate iteration counts in predictable implementer shapes, potentially avoiding unnecessary fallback to the lookup snippet.