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

Stack check inconsistency in interp_masm_x86 and sharedRuntime_x86

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P3
    • Resolution: Won't Fix
    • Affects Version/s: 9
    • Fix Version/s: tbd
    • Component/s: hotspot
    • Labels:

      Description

      There is an interesting code in sharedRuntime_x86_64:

          // Test if the oopMark is an obvious stack pointer, i.e.,
          // 1) (mark & 3) == 0, and
          // 2) rsp <= mark < mark + os::pagesize()
          // These 3 tests can be done by evaluating the following
          // expression: ((mark - rsp) & (3 - os::vm_page_size())),
          // assuming both stack pointer and pagesize have their
          // least significant 2 bits clear.
          // NOTE: the oopMark is in swap_reg %rax as the result of cmpxchg

          __ subptr(swap_reg, rsp);
          __ andptr(swap_reg, 3 - os::vm_page_size());

      Notice it checks the & 3 in the mark word. sharedRuntime_x86_32 does the same. But, interp_masm_x86 does 64-bit and 32-bit thing differently:

          const int zero_bits = LP64_ONLY(7) NOT_LP64(3);

          // Test if the oopMark is an obvious stack pointer, i.e.,
          // 1) (mark & zero_bits) == 0, and
          // 2) rsp <= mark < mark + os::pagesize()
          //
          // These 3 tests can be done by evaluating the following
          // expression: ((mark - rsp) & (zero_bits - os::vm_page_size())),
          // assuming both stack pointer and pagesize have their
          // least significant bits clear.
          // NOTE: the oopMark is in swap_reg %rax as the result of cmpxchg
          subptr(swap_reg, rsp);
          andptr(swap_reg, zero_bits - os::vm_page_size());

      It is hard to tell why we treat different bitnesses differently, and this was like this since revision 0 (Coleen had merged interp_masm_x86_{32,64} with JDK-8074717, not changing the block in question semantically).

      But, since there is a disconnect between what sharedRuntime and interp_masm do on x86_64, this might be the source of cryptic bugs? Need someone with expertise in this code to look at it.

        Attachments

          Activity

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            shade Aleksey Shipilev
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: