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

Vladimir Kozlov vladimir.kozlov at oracle.com
Mon Mar 11 17:46:32 PDT 2013


You did not rename layout_activation's parameter in few cppInterpreter 
files. Otherwise good.


On 3/11/13 8:51 AM, Roland Westrelin wrote:
> 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