RFR(S): 8009761: Deoptimization on sparc doesn't set Llast_SP correctly in the interpreter frames it creates

Roland Westrelin roland.westrelin at oracle.com
Mon Mar 11 08:51:24 PDT 2013


http://cr.openjdk.java.net/~roland/8009761/webrev.00/

The interpreter on sparc uses Llast_SP to keep track of SP at a call 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 what the return in B() just did. 

Roland.


More information about the hotspot-compiler-dev mailing list