[aarch64-port-dev ] RFR(S): 8248657: Windows: strengthening in ThreadCritical regarding memory model

Andrew Haley aph at redhat.com
Mon Jul 13 08:36:58 UTC 2020

On 13/07/2020 06:48, David Holmes wrote:
> Hi Thomas,
> On 13/07/2020 2:41 pm, Thomas Stüfe wrote:
>> Can a compiler reorder system calls and stores? How would it determine
>> if this is safe to do?

I very much doubt it.

> A compiler can reorder anything it likes if it can determine it is safe
> to do so. :)

I'm fairly sure the compiler doesn't care about that!

>> I'd be surprised if Microsoft loosened up reordering since this would
>> mean existing software cannot just be recompiled for arm and expected to
>> work. But this is just a guess of course.
> It's an interesting point because I would expect there to be a lot of
> software written for Windows that contains assumptions of TSO that would
> in fact fail when run on Aarch64. I don't know if there are any special
> mechanisms to force a binary to run in TSO mode on Aarch64 under Windows
> (or build flags), that would allow for ease of migration.

There's no standard hardware mechanism that would do so.

I've been very surprised at how little software has broken on AArch64
because of memory ordering. Like you, I initially assumed that stuff
would break all over the place, but by and large it was OK. I know of
two reasons: firstly, programmers are pretty conservative and tend to
use simple and reliable mechanisms such as safe publication and
mutexes for inter-thread communication. But also, and maybe more
importantly, the kinds of reordering the hardware can do are not very
different from those compilers do. Therefore, anyone playing fast and
loose with TSO has probably already been bitten by the compiler.

> But unless all Windows software will run in such a mode there is a
> need for MS to document what the memory consistency properties of
> various APIs are (as POSIX does [1]).

Indeed. I would have thought it existed somewhere.

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-runtime-dev mailing list