United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-8009761 : Deoptimization on sparc doesn't set Llast_SP correctly in the interpreter frames it creates

Details
Type:
Bug
Submit Date:
2013-03-11
Status:
Resolved
Updated Date:
2014-05-02
Project Name:
JDK
Resolved Date:
2013-03-13
Component:
hotspot
OS:
Sub-Component:
compiler
CPU:
Priority:
P4
Resolution:
Fixed
Affected Versions:
Fixed Versions:
hs25 (b23)

Related Reports
Backport:
Backport:
Backport:
Backport:
Relates:

Sub Tasks

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.
                                    

Comments
URL:   http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0094485b46c7
User:  amurillo
Date:  2013-03-15 22:31:21 +0000

                                     
2013-03-15
URL:   http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0094485b46c7
User:  roland
Date:  2013-03-13 12:31:51 +0000

                                     
2013-03-13



Hardware and Software, Engineered to Work Together