Change how TR_IPBCDataCallGraph entries are persisted into SCC #15617
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
dsouzai
reviewed
Aug 2, 2022
| _csInfo.setClazz(i, 0); | ||
| _csInfo._weight[i] = 0; | ||
| #ifdef PERSISTENCE_VERBOSE | ||
| fprintf(stderr, "loadFromPersistentCopy: Cannot convert ROMClass to RAMClass. Cannot get the class chain of ROMMethod\n"); |
There was a problem hiding this comment.
Suggested change
| fprintf(stderr, "loadFromPersistentCopy: Cannot convert ROMClass to RAMClass. Cannot get the class chain of ROMMethod\n"); | |
| fprintf(stderr, "loadFromPersistentCopy: Cannot convert ROMClass to RAMClass. Cannot get the class chain of ROMClass\n"); |
|
Also looks like there's a missing copyright update. |
Before this change, each `TR_IPBCDataCallGraph` entry that is persisted can contain up to 3 ROMClasses and their associates sampling frequencies. When loading from SCC we need to convert from a ROMClass to a RAMClass. This is done with the help of the `matchRAMclassFromROMclass()` frontend method, which first tries the classloader of the method being compiled and then the bootstrap classloader. If none of these attempts is successfull, we store NULL into the IProfiler entry which is created from the SCC entry. In this commit we change the mechanism to convert from a ROMClass to a RAMClass, to match the mechanism that is used in AOT relocation records. Specifically, the new code is using the mechanism that associates a classloader with the first class that is loaded by that class loader (see ClassLoaderTable.cpp). Thus, the IProfiler entry stored in SCC needs to contain two values now: (1) The classchain for the class that is being traked and (2) The classchain for the first class loaded by the classloader that loaded the class being tracked. Since in the new implementation we store more information, we will only track one target class instead of 3. This change is improving the throughput of some applications that rely on IProfiler information stored in SCC. Signed-off-by: Marius Pirvu <mpirvu@ca.ibm.com>
|
Fixed copyright message. |
Signed-off-by: Marius Pirvu <mpirvu@ca.ibm.com>
|
Addressed review comments |
dsouzai
approved these changes
Aug 5, 2022
|
jenkins test sanity.functional all jdk17 |
|
Tests have passed |
|
The test failure with the "Shared cache pointer out of bounds" assertion reported in #15609 appears to be the same race condition as discussed in #12405 and #12550. |
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.
Before this change, each
TR_IPBCDataCallGraphentry that is persisted can containup to 3 ROMClasses and their associates sampling frequencies. When loading from
SCC we need to convert from a ROMClass to a RAMClass. This is done with the
help of the
matchRAMclassFromROMclass()frontend method, which first triesthe classloader of the method being compiled and then the bootstrap classloader.
If none of these attempts is successfull, we store NULL into the IProfiler entry
which is created from the SCC entry.
In this commit we change the mechanism to convert from a ROMClass to a RAMClass,
to match the mechanism that is used in AOT relocation records. Specifically, the
new code is using the mechanism that associates a classloader with the first class
that is loaded by that class loader (see ClassLoaderTable.cpp).
Thus, the IProfiler entry stored in SCC needs to contain two values now:
(1) The classchain for the class that is being traked and
(2) The classchain for the first class loaded by the classloader that loaded the class
being tracked.
Since in the new implementation we store more information, we will only track one
target class instead of 3.
This change is improving the throughput of some applications that rely on IProfiler
information stored in SCC.
Depends on eclipse/omr#6638
Signed-off-by: Marius Pirvu mpirvu@ca.ibm.com