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

[Tobias Hartmann]

Thanks, Vladimir.

Best regards,
Tobias

On 16.02.19 01:37, Vladimir Ivanov wrote:
> 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
>>