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

Remove saving of RSP in Assembler::pusha_uncached()

    Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 15
    • Fix Version/s: 15
    • Component/s: hotspot
    • Subcomponent:
    • Resolved In Build:
      b24
    • CPU:
      x86
    • OS:
      generic

      Description

      In Assembler::pusha_uncached(), the value of RSP is stored with

      movq(Address(rsp, -5 * wordSize), rsp);

      together with all other register values. This, however, is only necessary for printing the value of RSP which currently happens at two places in the code. For all other uses of pusha, the actual value of RSP stored on the stack is not read/used. popa_uncached also just skips/ignores it since the value of RSP before pusha will automatically match the one after popa and does not need to be restored from the stack. Therefore, we could get rid of

      movq(Address(rsp, -5 * wordSize), rsp);

      and adjust the two places in the code such that print the value of RSP by computing the value from the new stack pointer after pusha.

      If there are some reasonable concerns to keep storing it, we should still change the code in pusha_uncached(). As Erik has pointed out, the code assumes that saving RSP in a slot of the red zone (before decrementing RSP) is okay. The red zone is an area, at least 128 bytes long, below RSP, which in the Sys-V ABI is guaranteed to not get clobbered by the OS. There is a comment stating that the ABI promises not to clobber this memory. But the windows ABI does not have a red zone. So if you are unlucky, and get an interrupt between saving the RSP and decrementing the RSP, then RSP will get corrupted on windows. This could be fixed by replacing the movq for RSP by computing RSP after decrementing it first:

      subq(rsp, 16 * wordSize);
      movq(Address(rsp, 11 * wordSize), rsp);
      addq(Address(rsp, 11 * wordSize), 16 * wordSize);

        Attachments

          Activity

            People

            • Assignee:
              chagedorn Christian Hagedorn
              Reporter:
              eosterlund Erik Ă–sterlund
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: