JDK-8009761 : Deoptimization on sparc doesn't set Llast_SP correctly in the interpreter frames it creates
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-03-11
  • Updated: 2014-05-02
  • Resolved: 2013-03-13
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 7 JDK 8 Other
7u40Fixed 8Fixed hs24Fixed
Related Reports
Relates :  
JDK-8021775 - compiler/8009761/Test8009761.java "Failed: init recursive calls: 51. After deopt 50"
Description
The interpreter on sparc uses Llast_SP to keep track of SP at a call in case in case adapters bump SP. It uses O5_savedSP/I5_savedSP to keep track of SP at a call as well, but because a call to an interpreted method may bump SP to allocate space for locals of the callee in the caller. O5_savedSP/I5_savedSP is used to restore SP of the caller from the callee in the return bytecode. Llast_SP is used from the interpreter return entry point in the caller to restore SP.
Deoptimization sets O5_savedSP/I5_savedSP to account for the extra locals correctly but it sets Llast_SP to the same as SP with the extra locals.
If A() inlines B() and deoptimization happens in B(), A and B's frames will be set up by the deoptimization code so that when B() returns: SP is restored to I5_savedSP (without the extra locals) and then when the thread is back in A(), SP is set to Llast_SP, with the extra locals, undoing the what the return in B() just did.