-
Bug
-
Resolution: Fixed
-
P4
-
None
-
b23
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8010348 | 8 | Roland Westrelin | P4 | Resolved | Fixed | b82 |
JDK-8018078 | 7u45 | Roland Westrelin | P4 | Closed | Fixed | b01 |
JDK-8011338 | 7u40 | Roland Westrelin | P4 | Closed | Fixed | b19 |
JDK-8010985 | hs24 | Roland Westrelin | P4 | Resolved | Fixed | b38 |
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.
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.
- backported by
-
JDK-8010348 Deoptimization on sparc doesn't set Llast_SP correctly in the interpreter frames it creates
- Resolved
-
JDK-8010985 Deoptimization on sparc doesn't set Llast_SP correctly in the interpreter frames it creates
- Resolved
-
JDK-8011338 Deoptimization on sparc doesn't set Llast_SP correctly in the interpreter frames it creates
- Closed
-
JDK-8018078 Deoptimization on sparc doesn't set Llast_SP correctly in the interpreter frames it creates
- Closed
- relates to
-
JDK-8021775 compiler/8009761/Test8009761.java "Failed: init recursive calls: 51. After deopt 50"
- Resolved