8266854: LibraryCallKit::inline_preconditions_checkIndex modifies control flow even if the intrinsic bailed out #114
Conversation
…trol flow even if the intrinsic bailed out
|
@sviswa7 This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 16 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.
|
Webrevs
|
Created a separate RFE for test case https://bugs.openjdk.java.net/browse/JDK-8269107. |
@@ -1032,17 +1032,17 @@ bool LibraryCallKit::inline_preconditions_checkIndex(BasicType bt) { | |||
Deoptimization::Action_make_not_entrant); | |||
} | |||
|
|||
if (stopped()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @sviswa7, comments over both the short-circuiting exits will help in better code readability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jatin-bhateja Added comments, please take a look.
@vnkozlov Can I go ahead and integrate this into JDK 17? |
/integrate |
Going to push as commit b474314.
Your commit was automatically rebased without conflicts. |
Yes, you can and you did already |
LibraryCallKit::inline_preconditions_checkIndex can result in the following assert sometimes:
"# assert(ctrl == kit.control()) failed: Control flow was added although the intrinsic bailed out"
Consider the following code snippet:
...
set_control(_gvn.transform(new IfTrueNode(rc)));
{
PreserveJVMState pjvms(this);
set_control(_gvn.transform(new IfFalseNode(rc)));
uncommon_trap(Deoptimization::Reason_range_check,
Deoptimization::Action_make_not_entrant);
}
..
Here the control is being modified by set_control and afterwards a bailout happens.
The fix is as per discussion on openjdk/jdk#3958.
Best Regards,
Sandhya
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk17 pull/114/head:pull/114
$ git checkout pull/114
Update a local copy of the PR:
$ git checkout pull/114
$ git pull https://git.openjdk.java.net/jdk17 pull/114/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 114
View PR using the GUI difftool:
$ git pr show -t 114
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk17/pull/114.diff