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

more fencing needed in async deflation for non-TSO machines



    • Bug
    • Resolution: Fixed
    • P3
    • 15
    • 15
    • hotspot
    • b33
    • arm, ppc
    • linux



        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


          Issue Links



                dcubed Daniel Daugherty
                dcubed Daniel Daugherty
                0 Vote for this issue
                1 Start watching this issue