JDK-8210686 : [AOT] crash after deoptimization of AOT method
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2018-09-12
  • Updated: 2023-07-21
  • Resolved: 2023-07-21
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
12Resolved
Related Reports
Duplicate :  
JDK-8210256 - [AOT] crash happens when some of vm/jdwp test cases are executed
Duplicate :  
JDK-8210777 - Update Graal
Description
When running the vm/jdwp/ClassType/NewInstance/newinst001/newinst001 JCK test with the test classes in an AOT library, there is a crash after javasoft/sqe/tests/vm/jdwp/ClassType/NewInstance/newinst001a.runIt is deoptimized.
Comments
ILW = same as 8210256 = P3
13-09-2018
Thanks. I see that we do the pop before creating the FrameState for the classInitializationPlugin.
13-09-2018
No, that's unlikely due to elimination. Initialization nodes are assigned precise frame states that are passed to initialization plugin. That frame state should have this 100 on stack. If there is a bug - it's there, it is passed a wrong frame state.
13-09-2018
[~iveresov] Igor, do you think this could be related to the static initializer elimination phase that you wrote?
13-09-2018
ScopeDesc looks like this: ScopeDesc(pc=0x00007f149d1c64d0 offset=2b0): javasoft.sqe.tests.vm.jdwp.ClassType.NewInstance.newinst001a::runIt@17 (line 45) reexecute=true Locals - l0: empty - l1: empty - l2: empty Note that there is no "Expression stack".
13-09-2018
The bytecodes where we deopt are: 15: bipush 100 17: putstatic #12 // Field javasoft/sqe/tests/vm/jdwp/ClassType/NewInstance/newinst001a$TestedObjectClass.foo:I The deoptimize while calling Stub<initialize_klass_by_symbol(Word,Word)Word> for the putstatic. When we return to the interpreter, putstatic expects the value on the stack and does a pop, but nothing has been pushed, so we end up with the interpreter_frame_initial_sp_offset slot unprotected and it eventually gets overwritten.
12-09-2018