RFR: JDK-8035496: G1 ARM: missing remset entry noticed by VerifyAfterGC for vm/gc/concurrent/lp50yp10rp70mr30st0

[Vitaly Davidovich]

Isn't this going to emit a full fence on x86/64? Is storestore insufficient?

Also, is the load side ordered properly already?

sent from my phone
On May 13, 2015 3:17 PM, "Thomas Schatzl" <thomas.schatzl at oracle.com> wrote:

> Hi Bengt,
>
> On Wed, 2015-05-13 at 20:41 +0200, Bengt Rutisson wrote:
> > Hi Jon and Thomas,
> >
> > On 13/05/15 19:48, Thomas Schatzl wrote:
> > > Hi,
> > >
> > > On Wed, 2015-05-13 at 09:42 -0700, Jon Masamitsu wrote:
> > >> Bengt,
> > >>
> > >> Change looks good.
> >
> > Thanks for the review, Jon!
> >
> > >>
> > >> Thomas,
> > >>
> > >> Is the comment added as part of this change understandable to
> > >> you?  I don't know this code so definitely lack the greater
> > >> understanding of what's going on.   But if you think the
> > >> comment is clear (and since you know the context), it's
> > >> fine.
> > >    it's fine, except maybe for the comment about non-TSO architectures.
> > > It just means that the last write publishes the data structure to the
> > > public, so everything written before that should be guaranteed to be
> > > written first.
> > >
> > > As for the comment about non-TSO architectures, TSO architectures also
> > > need that barrier because the compiler might otherwise reorder the
> > > writes which then definitely gets visible in the wrong order.
> > >
> > > Maybe Bengt can fix that (just remove the "On non-TSO systems," part)
> > > before pushing?
> >
> > Sounds good. I'll remove that sentence before I push.
> >
>
> It is sufficient to remove just the three words imo :)
>
> Thanks,
>   Thomas
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150513/dc08b32e/attachment.htm>