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

Tobias Hartmann tobias.hartmann at oracle.com
Fri Feb 15 14:19:13 UTC 2019


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


More information about the hotspot-compiler-dev mailing list