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

    Details

    • Subcomponent:
    • Resolved In Build:
      b23

      Backports

        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.

          Attachments

            Issue Links

              Activity

                People

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

                  Dates

                  • Created:
                    Updated:
                    Resolved: