-
Bug
-
Resolution: Fixed
-
P3
-
17
-
b28
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8269444 | 18 | Sandhya Viswanathan | P3 | Resolved | Fixed | b04 |
JDK-8270631 | 17.0.1 | Sandhya Viswanathan | P3 | Resolved | Fixed | b03 |
LibraryCallKit::inline_preconditions_checkIndex can result in "# assert(ctrl == kit.control()) failed: Control flow was added although the intrinsic bailed out" sometimes.
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 even though a bailout is possible afterwards.
Moving the set_control later in the intrinsic fixes this.
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 even though a bailout is possible afterwards.
Moving the set_control later in the intrinsic fixes this.
- backported by
-
JDK-8269444 LibraryCallKit::inline_preconditions_checkIndex modifies control flow even if the intrinsic bailed out
-
- Resolved
-
-
JDK-8270631 LibraryCallKit::inline_preconditions_checkIndex modifies control flow even if the intrinsic bailed out
-
- Resolved
-
- relates to
-
JDK-8269107 Create a test case for JDK-8266854
-
- Open
-
(1 links to)