RFR (XS): 8188877: Improper synchronization in offer_termination
thomas.schatzl at oracle.com
Mon Nov 27 09:32:01 UTC 2017
On Mon, 2017-11-27 at 10:30 +0100, Thomas Schatzl wrote:
> Hi all,
> On Wed, 2017-11-22 at 09:13 +0000, 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.
> > > Either kind of read will eventually notice that its local cached
> > > value has been invalidated and will fetch the updated value.
> > Eventually, yes.
> so, summing up this discussion, the change is good to go? I think
> we can always add any implementation dependent optimizations later.
> If everybody agrees, I will push it.
and btw, looks good :)
More information about the hotspot-gc-dev