RFR(S): 8229422: Taskqueue: Outdated selection of weak memory model platforms
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.
> -----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
> Andrew Haley (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the hotspot-gc-dev