[jdk16] RFR: 8259276: C2: Empty expression stack when reexecuting tableswitch/lookupswitch instructions after deoptimization

[Vladimir Ivanov]

On Mon, 25 Jan 2021 08:02:08 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> During parsing of `lookupswitch` and `tableswitch` instructions C2 may insert a safepoint. Corresponding JVM state has always re-execute bit set since the interpreter will unconditionally re-execute the instruction after deoptimization is over (see `AbstractInterpreter::bytecode_should_reexecute` for the full list of instructions).  
>> 
>> But `Parse::do_tableswitch()`/`Parse::do_lookupswitch()` attach wrong JVM state: it describes the state **after** the instruction since the first thing they do is they pop the operand from the expression stack. Instead, the JVM state **before** the instruction should be used to respect the re-execution in the interpreter. 
>> 
>> The bug manifests as a stack corruption after deoptimization at a broken safepoint.
>> 
>> The fix is to keep the initial JVM state (before the instruction) intact until all the safepoints at the particular instruction are inserted.   
>> 
>> Testing:
>> - [ ] hs-tier1 - hs-tier7 (in progress)
>> - [ ] Kitchensink24h w/ -XX:+DeoptimizeALot (in progress)
>
> Looks good. Just wondering, although this triggers with stress testing, should we still add a targeted regression test? (Can be done later, since this is for JDK 16).

Thanks for the reviews, Dean, Vladimir, and Tobias.

> Just wondering, although this triggers with stress testing, should we still add a targeted regression test? (Can be done later, since this is for JDK 16).

The fix introduces an assert which reliably fires during compilation with the problematic test case (Kitchensink). So, I see less value in a dedicated regression test now.

-------------

PR: https://git.openjdk.java.net/jdk16/pull/130