Expand bytecode offset variables to 32bit - #6999
Merged
Merged
Conversation
klangman
requested review from
0xdaryl,
Leonardo2718,
mstoodle and
vijaysun-omr
as code owners
May 23, 2023 20:50
Contributor
Author
|
This is the OMR side change that supports OpenJ9 changes to address the reported issue described above. I tested both the combined changes and the OMR changes alone and both passed. It's possible that the OpenJ9 changes would also pass independent of the OMR changes, but I will wait for these changes to merge before submitting the OpenJ9 changes. |
Contributor
Author
|
Oops. My testing did not have asserts enabled. I will fix that test failure. |
A user experienced a compile time crash in setHandlerInfoWithOutBCInfo() because a bytecode index to a catch handler is above the 2^16th limit that normally applies for Java methods. This limit can be exceeded in rare cases after the JVM expands the method size on load. A good example of this would be when the VM inlines a "jsr" bytecode. Because the handler index is larger then 2^16th the offset is truncated when it is placed into the 16bit integer that we were using to record the offset. This fix will expand the size of variables used to hold bytecode offsets to be 32bits. Signed-off-by: Kevin Langman <langman@ca.ibm.com>
klangman
force-pushed
the
16bit-bc-offset-fix
branch
from
May 23, 2023 21:15
af649ad to
d5be906
Compare
vijaysun-omr
approved these changes
May 23, 2023
Contributor
|
jenkins build all |
Contributor
|
jenkins build riscv |
1 similar comment
Contributor
|
jenkins build riscv |
|
fyi your riscv failure above is not your code. I'm adding |
Contributor
|
Merging this since all other checks have passed and the change itself looks like a valid one to me. |
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.
A user experienced a compile time crash in setHandlerInfoWithOutBCInfo() because a bytecode index to a catch handler is above the 2^16th limit that normally applies for Java methods. This limit can be exceeded in rare cases after the JVM expands the method size on load. A good example of this would be when the VM inlines a "jsr" bytecode. Because the handler index is larger then 2^16th the offset is truncated when it is placed into the 16bit integer that we were using to record the offset. This fix will expand the size of variables used to hold bytecode offsets to be 32bits.