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

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Oct 27 15:04:29 UTC 2015

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?


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

Roland, what do you think?


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

More information about the hotspot-compiler-dev mailing list