RFR (XS): 8188877: Improper synchronization in offer_termination

Andrew Haley aph at redhat.com
Wed Nov 22 09:13:05 UTC 2017

On 21/11/17 21:53, White, Derek wrote:
> My understanding is that the "acquire" semantics are entirely about
> memory ordering, within a CPU. In particular it prevents "following
> loads" from executing before the "load acquire".
> There is nothing in the "load acquire" that causes it to synchronize
> with the memory system more or less quickly than a naked load.

The abstract architecture only specifies things in terms of ordering
between loads, but it has to be implemented somehow, and this is MESI
or something similar.  Stores cause invalidate messages to be sent,
and these are put into the reader's invalidate queue.  When that
reader executes a load barrier it marks all the entries currently in
its invalidate queue.  The next load will wait until all marked
entries have been applied to the reader's cache.

> Either kind of read will eventually notice that its local cached
> value has been invalidated and will fetch the updated value.

Eventually, yes.

Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

More information about the hotspot-gc-dev mailing list