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

OrderAccess::fence must guarantee visibility

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P2
    • Resolution: Not an Issue
    • Affects Version/s: 8u152, 9
    • Fix Version/s: 9
    • Component/s: hotspot
    • Labels:
      None

      Description

      The description of OrderAccess::fence is currently given as:

      // Finally, we define a "fence" operation, as a bidirectional barrier.
      // It guarantees that any memory access preceding the fence is not
      // reordered w.r.t. any memory accesses subsequent to the fence in program
      // order. This may be used to prevent sequences of loads from floating up
      // above sequences of stores.

      but later is this snippet:

      // Use
      // release_store_fence to update values like the thread state, where we
      // don't want the current thread to continue until all our prior memory
      // accesses (including the new thread state) are visible to other threads.

      The visibility property of the fence() is not clearly documented but is critical for correct operation of algorithms utilising the dekker-duality - such as the safepoint porotocol.

      There is an interesting discussion at:

      https://blogs.oracle.com/dave/entry/qpi_quiescence

      where Dice states in relation to "fences" (on x86 and SPARC):

      "That is, they don't force anything to happen -- such as coherence messages on the bus -- that were not already destined to occur. Instead, they simply enforce an order, momentarily reconciling program and memory order."

      This might be misconstrued as fences not ensuring visibility, but it simply means that it is done by "passive" means. Given the Dekker sequences:

      st B, x
      fence
      ld A

      and

      st A, y
      fence
      ld B

      either the ld A sees y, or the ld B sees x, or possibly both. But it is not possible that neither x nor y are seen.

      This requirement needs to be clearly documented and the implementations use the appropriate platform barrier instructions.

        Attachments

          Activity

            People

            • Assignee:
              dholmes David Holmes
              Reporter:
              dholmes David Holmes
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: