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

Doerr, Martin martin.doerr at sap.com
Tue Jan 14 16:19:32 UTC 2020


Excellent. I'd propose the same fix.

I've added Thomas Schatzl. Maybe he can have a look, too.

Best regards,
Martin


> -----Original Message-----
> From: Andrew Haley <aph at redhat.com>
> Sent: Dienstag, 14. Januar 2020 17:16
> To: Doerr, Martin <martin.doerr at sap.com>; Derek White
> <derekw at marvell.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:52 PM, Doerr, Martin wrote:
> 
> > 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.
> 
> Good, I thought so.
> 
> Given that TSO machines define OrderAccess::acquire() as no more than
> a compiler barrier, I believe that we could do something like
> 
> #ifdef CPU_MULTI_COPY_ATOMIC
>    OrderAccess::acquire();
> #else
>    OrderAccess::fence();
> #endif
> 
> --
> 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



More information about the hotspot-gc-dev mailing list