Expand bytecode offset variables to 32bit #6999
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
klangman
requested review from
mstoodle,
Leonardo2718,
vijaysun-omr and
0xdaryl
as code owners
|
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. |
|
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 <[email protected]>
klangman
force-pushed
the
16bit-bc-offset-fix
branch
from
af649ad
to
d5be906
Compare
vijaysun-omr
approved these changes
May 23, 2023
|
jenkins build all |
|
jenkins build riscv |
1 similar comment
|
jenkins build riscv |
|
fyi your riscv failure above is not your code. I'm adding |
|
Merging this since all other checks have passed and the change itself looks like a valid one to me. |
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.
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.