Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8009761

Deoptimization on sparc doesn't set Llast_SP correctly in the interpreter frames it creates

XMLWordPrintable

    • b23

        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.

              roland Roland Westrelin
              roland Roland Westrelin
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: