RFR (XS): 8188877: Improper synchronization in offer_termination

Andrew Dinn adinn at redhat.com
Mon Nov 27 12:30:37 UTC 2017

On 22/11/17 09:13, Andrew Haley wrote:
> 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.

That's what happens when the reader executes a read barrier. The
interesting question is what happens when the reader does not execute a
read barrier.

>> Either kind of read will eventually notice that its local cached
>> value has been invalidated and will fetch the updated value.
> Eventually, yes.
That's a rather ill-defined span of time ;-)

I understand that you tested this and found that it took no longer than
a few hundred microseconds. However, I really have to ask what precisely
the reader was doing during the test?

Specifically, does the time taken to 'eventually' notice a write to the
LDRed location depend upon what other instructions are executed between
successive LDRs?


Andrew Dinn
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

More information about the hotspot-gc-dev mailing list