RFR(S): 8218721: C1's CEE optimization produces safepoint poll with invalid debug information
martin.doerr at sap.com
Mon Feb 18 14:34:49 UTC 2019
the fix looks good. Thank you.
I think the comment "If will be eliminated by CEE" should get updated for test1, test2, test6.
Maybe "If got eliminated by CEE before JDK-8218721"?
(Don't need to see another webrev for such comment changes.)
Thanks for implementing the test for class file version 52. I guess this change will get an Oracle backport label.
Thanks for fixing.
From: hotspot-compiler-dev <hotspot-compiler-dev-bounces at openjdk.java.net> On Behalf Of Tobias Hartmann
Sent: Montag, 18. Februar 2019 08:25
To: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>; hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
Subject: Re:  RFR(S): 8218721: C1's CEE optimization produces safepoint poll with invalid debug information
On 16.02.19 01:37, Vladimir Ivanov wrote:
> Looks good.
> Best regards,
> Vladimir Ivanov
> On 15/02/2019 06:19, Tobias Hartmann wrote:
>> please review the following patch:
>> 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.
More information about the hotspot-compiler-dev