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

more fencing needed in async deflation for non-TSO machines

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 15
    • Fix Version/s: 15
    • Component/s: hotspot
    • Subcomponent:
    • Resolved In Build:
      b33
    • CPU:
      arm, ppc
    • OS:
      linux

      Backports

        Description

        Erik O. sent more mullings on the recent JDK-8153224 bits:

        On 6/4/20 5:36 AM, Erik Österlund wrote:
        > Hi Dan,
        >
        > ObjectMonitor::set_allocation_state needs a release_store, and ObjectMonitor::allocation_state
        > needs a load_acquire, instead of plain loads and stores. In particular the is_old() function
        > used by the service thread to check if we should deflate, should probably use load_acquire.
        >
        > The reasoning is that the service thread checks if allocation_state() is old, and assumes that
        > values read from the monitor/markWord will not be stale values from before the monitor was initialized
        > as being bound to the new object. In particular, I am worried that the store of the markWord pointing
        > at the monitor, and the store publishing it as old, get reordered. Then, a concurrent deflation thread
        > could consider the monitor a candidate for deflation, before the markWord of the object has been
        > linked to the ObjectMonitor.
        >
        > On TSO machines, this won't matter, but on other machines it will (AArch64 and PPC).
        >
        > I'm not quite sure if anything more serious than a memory leak will happen in this rather narrow
        > race condition (the deflation fails and never gets considered for deflation again, as the monitor
        > is left in an unexpected state). Nevertheless, I think we should fix it.
        >
        > Sorry I didn't catch this during the review.
        >
        > /Erik

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  dcubed Daniel Daugherty
                  Reporter:
                  dcubed Daniel Daugherty
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  1 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: