JDK-8209825 : guarantee(false) failed: wrong number of expression stack elements during deopt
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-08-22
  • Updated: 2022-02-01
  • Resolved: 2018-08-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 12
12 b09Fixed
Related Reports
Relates :  
JDK-8278874 - VerifyStack logic is too permissive
Relates :  
JDK-8148871 - Possible wrong expression stack depth at deopt point
Description
I hit this guarantee while using -XX:+VerifyStack.  The problem is similar to JDK-8148871.  I've added a test case to TestVerifyStackAfterDeopt.java to reproduce it.
Comments
URL: http://hg.openjdk.java.net/jdk/jdk/rev/b426c75da4b9 User: dlong Date: 2018-08-24 18:57:46 +0000
24-08-2018
http://cr.openjdk.java.net/~dlong/8209825/webrev/
22-08-2018
It looks like "top_frame_expression_stack_adjustment" should take care of the fact that bytecodes like anewarray deopt in an "almost finished" state. However, if the following bytecode is an invoke, we do: next_mask_expression_stack_size = invoke.size_of_parameters(); but I don't see where we take into account the stack size before or after the invoke. The above line assumes that stack is empty when we pushed the parameters.
22-08-2018
ILW = Guarantee failure with verification code, with -XX:+VerifyStack, no workaround = MLH = P4
22-08-2018
I'm guessing the problem is that both C1 and C2 pop the size value off the stack before generating the frame state for the slow call. There is no bci that exactly matches this state. It seems like for the top frame, we should try to match the interpreter "state after", so we need to adjust by the size pushed by the bytecode.
22-08-2018