[9] RFR(S): 8140574: C2 must re-execute checks after deoptimizing from merged uncommon traps

[Vladimir Kozlov]

Note is_uncommon_trap_proj(Deoptimization::Reason_none) returns value 
for ANY reasons. Your change is limiting it to only one. We may fold 
less because of that.

Should we just additionally check re-execute flag?

dom_unc->jvms()->should_reexecute()

Unfortunately wee can't change reexecute flag since JVM state is already 
recorded according to it.

Roland, what do you think?

Thanks,
Vladimir


On 10/27/15 7:17 PM, Tobias Hartmann wrote:
> Hi,
>
> please review the following patch.
>
> https://bugs.openjdk.java.net/browse/JDK-8140574
> http://cr.openjdk.java.net/~thartmann/8140574/webrev.00/
>
> Problem:
> C2 merges the branches for an If and the dominating If into a single region that branches to the uncommon trap for the dominating If to optimize explicit range checks. The problem is that if the dominating If branches to an uncommon trap with 'Reason_unloaded', the merged uncommon trap will not re-execute the checks but directly execute the branch of the first If. This leads to wrong code being executed. Since we don't know which of the two checks failed, we have to re-execute both.
>
> Solution:
> As Roland pointed out, IfNode::has_only_uncommon_traps() should check if the dominating uncommon trap has 'Reason_unstable_if' to ensure that we re-execute the bytecode after deoptimization. The type of the dominated uncommon trap does not matter in this case.
>
> Testing:
> Regression test and JPRT. I also compared the PrintOptoAssembly output of TestExcplicitRangChecks to the baseline version to make sure that all range checks are still folded.
>
> Thanks,
> Tobias
>