RFR (XS): 8188877: Improper synchronization in offer_termination

[White, Derek]

Thomas, Kim, Andrew, Andrew,

Thanks for the review comments and push!

 - Derek

> -----Original Message-----
> From: Thomas Schatzl [mailto:thomas.schatzl at oracle.com]
> Sent: Monday, November 27, 2017 4:32 AM
> To: Andrew Haley <aph at redhat.com>; White, Derek
> <Derek.White at cavium.com>; Kim Barrett <kim.barrett at oracle.com>
> Cc: hotspot-gc-dev at openjdk.java.net
> Subject: Re: RFR (XS): 8188877: Improper synchronization in
> offer_termination
> 
> Hi again,
> 
> 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 :)
> 
> Thomas