8259276: C2: Empty expression stack when reexecuting tableswitch/lookupswitch instructions after deoptimization #130
Conversation
…upswitch instructions after deoptimization
|
@iwanowww This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been no new commits pushed to the
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make sense.
Add Fix request for JDK 16 to bug report. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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. |
Okay, fair enough. |
/integrate |
@iwanowww Since your change was applied there has been 1 commit pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 81e730e. |
During parsing of
lookupswitch
andtableswitch
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 (seeAbstractInterpreter::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:
Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jdk16 pull/130/head:pull/130
$ git checkout pull/130