[13] RFR(S): 8218721: C1's CEE optimization produces safepoint poll with invalid debug information

[Vladimir Ivanov]

Looks good.

Best regards,
Vladimir Ivanov

On 15/02/2019 06:19, Tobias Hartmann wrote:
> Hi,
> 
> please review the following patch:
> https://bugs.openjdk.java.net/browse/JDK-8218721
> http://cr.openjdk.java.net/~thartmann/8218721/webrev.00/
> 
> C1's Conditional Expression Elimination (CEE) searches for an if that has two branches that only set
> a value and then directly jump to the same target block. CEE then replaces this if by a conditional
> expression and a single goto to the target block.
> 
> This is problematic if one of the gotos is a safepoint but the if is not (for example, see
> TestGotoIf::test1/test2). In this case, the resulting goto is marked as a safepoint but there is no
> valid state_before. In product, we end up with a safepoint poll in C1 compiled code that has invalid
> debug information which leads to a corrupted stack after deoptimization (more information is in the
> bug comments). With a debug build, we hit a corresponding assert.
> 
> I first thought of just omitting the safepoint if there's no state_before information available.
> However, this can lead to long running loops without safepoint polls (see test6 as an example).
> 
> Therefore, and since this is a rare case, I've decided to bail out if one of the gotos is a
> safepoint but the if is not. None of our tests (hs-tier1-3 and hs-precheckin-comp) trigger this
> scenario because javac does not seem to generate such bytecode sequences. The optimization still
> works fine for test3, test4 and test5 because there the if has safepoint information.
> 
> Thanks,
> Tobias
>