more fencing needed in async deflation for non-TSO machines

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