Create TR_IPBCDataDirectCall for IProfiler #21874
Merged
Conversation
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
mpirvu
force-pushed
the
iprofiler_directcalls
branch
from
3499bb6 to
f9d568f
Compare
|
jenkins compile all jdk8,jdk21 |
|
jenkins test sanity all jdk21 |
|
Windows failed one test: I have also looked at performance of this PR and there might be a small perf regression ~3.5% |
mpirvu
force-pushed
the
iprofiler_directcalls
branch
from
f9d568f to
bce0daf
Compare
|
I fixed the performance regression in the latest forced push. |
|
@dsouzai Could you please review/merge this PR? Thanks |
dsouzai
approved these changes
May 16, 2025
|
I will update now. |
The IProfiler does not collect samples for direct calls. Instead, the optimizer will use the setCallCount() API to set the number of samples for such direct calls. Until this commit, direct-call info was stored in TR_IPBCDataCallGraph entries which was mainly created for interface and virtual calls. Such entries track 3 different call targets and are somewhat bigger than the rest of IProfiler entries. For direct calls we only need a simple counter, so using TR_IPBCDataCallGraph entries for this purpose is wasteful. This commit introduces a new type of IProfiler entry, called TR_IPBCDataDirectCall, which will be used for storing profiling info related to direct calls. Note that the optimizer will remain the sole entity that will populate such entries. Moreover, these new entries will not be stored into the SCC (this follows the existing approach where profiling info related to direct calls is not stored in SCC). Signed-off-by: Marius Pirvu <[email protected]>
mpirvu
force-pushed
the
iprofiler_directcalls
branch
from
bce0daf to
16ec425
Compare
|
Updated the code with the correct memory tag from OMR. |
|
jenkins test sanity.functional all jdk21 |
dsouzai
approved these changes
May 16, 2025
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 IProfiler does not collect samples for direct calls. Instead, the optimizer will use the setCallCount() API to set the number of samples for such direct calls. Until this commit, direct-call info was stored in
TR_IPBCDataCallGraphentries which was mainly created for interface and virtual calls. Such entries track 3 different call targets and are somewhat bigger than the rest of IProfiler entries. For direct calls we only need a simple counter, so usingTR_IPBCDataCallGraphentries for this purpose is wasteful.This commit introduces a new type of IProfiler entry, called
TR_IPBCDataDirectCall, which will be used for storing profiling info related to direct calls. Note that the optimizer will remain the sole entity that will populate such entries. Moreover, these new entries will not be stored into the SCC (this follows the existing approach where profiling info related to direct calls is not stored in SCC).