- 
    Bug 
- 
    Resolution: Fixed
- 
     P3 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)
        
     
        