Correct the handling of hidden class field comparisions #18374
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
hzongaro
reviewed
Oct 30, 2023
nbhuiyan
force-pushed
the
hidden-cls
branch
2 times, most recently
from
d8dc0be to
32fda13
Compare
This was referenced Nov 6, 2023
Closed
hzongaro
reviewed
Nov 7, 2023
When using jitFieldsAreSame to compare the fields of two distinct hidden classes, the result can be a false positive if the field names and data types match. This can result in disastrous symref sharing for hidden class stores/loads. Hidden classes generated within the same host class do not have distinct class names, but share the same field names with different field data types and offsets. Therefore, name-based check for whether fields are same can result in false positives when it comes to hidden classes unless the fields are from the same j9class objects. Signed-off-by: Nazim Bhuiyan <[email protected]>
Using jitFieldsAreSame to check two different fields can yield false positives if the fields belong to two different hidden class instances within the same host class. By checking if the fields belong to hidden classes, we can prevent false positives when dealing with hidden class fields, which will prevent incorrect field shadow symref sharing. This commit includes the following: * Added TR_J9ServerVM override for isHiddenClass * Added check in TR_J9ServerVM::jitFieldsAreSame using this new helper Signed-off-by: Nazim Bhuiyan <[email protected]>
|
@hzongaro I have expanded the commit msg for the JITServer changes. |
|
Jenkins test sanity all jdk11,jdk17,jdk21 |
|
Failures for aarch64 Linux jdk11 and jdk21 and Power Linux jdk17 appear to be infrastructure related. Restarting those. I'll look through the other failures. Jenkins test sanity alinux64 jdk11,jdk21 |
|
Jenkins test sanity plinux jdk17 |
|
I investigated failures in the test runs that have completed:
Update: Linux ppc64le JDK 17 failures are due to issue #18144 (or #17457) |
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.
When using jitFieldsAreSame to compare the fields of two distinct hidden classes, the result can be a false positive if the field names and data types match. This can result in disastrous symref sharing for hidden class stores/loads.
Hidden classes generated within the same host class do not have distinct class names, but share the same field names with different field data types and offsets. Therefore, name-based check for whether fields are same can result in false positives when it comes to hidden classes unless the fields are from the same j9class objects.