RFR(S): 8229422: Taskqueue: Outdated selection of weak memory model platforms

[Doerr, Martin]

Hi Andrew,

good catch. I think you're right. A multi-copy-atomic, but weak architecture (e.g. aarch64) needs an instruction which orders both volatile loads.
(IA64 compilers use acquiring loads when accessing volatile fields, that's why IA64 is not affected by this problem.)

Best regards,
Martin


> -----Original Message-----
> From: Andrew Haley <aph at redhat.com>
> Sent: Dienstag, 14. Januar 2020 16:09
> To: Derek White <derekw at marvell.com>; Doerr, Martin
> <martin.doerr at sap.com>; David Holmes <david.holmes at oracle.com>;
> hotspot-gc-dev at openjdk.java.net; Kim Barrett <kim.barrett at oracle.com>
> Subject: Re: RFR(S): 8229422: Taskqueue: Outdated selection of weak
> memory model platforms
> 
> On 1/14/20 3:05 PM, Andrew Haley wrote:
> > On 1/14/20 3:00 PM, Andrew Haley wrote:
> >> On 8/15/19 4:49 PM, Derek White wrote:
> >>> However, setting CPU_MULTI_COPY_ATOMIC for AArch64 would result
> in changing behavior (removing fence in taskqueue) that should be looked at
> and tested by the aarch64 folks, so if Andrew Haley agrees, I suggest
> deferring changing this AArch64 behavior to a separate issue.
> >>
> >> Well, yes. What i don't understand is what any of this has to do with
> >> multi-copy atomicity. The fence is needed for _age.get() on all machines
> >> with relaxed memory consitency, AFAICS.
> >
> > Ah, I found the answer in another thread:
> >
> > http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-
> March/008853.html
> 
>    "No, the problem is not reordering.  The problem is that _bottom,
>    which is read after _age, might be older than _age because another
>    processor didn't write it back yet.  The fence (sync) makes the
>    current thread wait until it has the new _bottom.
> 
>    "On Power, a write is not visible to all other threads simultaneously
>    (no multipl-copy-atomicity)."
> 
> So, my question: on a machine with relaxed memory, do we still need an
> acquire
> fence?
> 
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671