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

[Ludovic Henry]

Hello,

> But if we are dealing with non-TSO races then it would be good to get
> some guidance from Microsoft as to the memory ordering properties of
> various API's to ensure that we are maintaining correct ordering. For
> example, in the destructor we have:
> 
> 81     lock_owner = 0;
> 82     // No lost wakeups, lock_event stays signaled until reset.
> 83     DWORD ret = SetEvent(lock_event);
> 
> but unless we are guaranteed that the store to lock_owner cannot be
> reordered by the compiler or the hardware, to appear to be after the
> SetEvent, then the logic is broken. Generally, because Windows only
> supported TSO systems, we have assumed that the compiler will not
> reorder code across these kind of API calls. But now we also need
> hardware guarantees.

I can confirm that calls such as SetEvent have an implicit memory barrier as they are syscalls. This specific instance would then not suffer from any memory reordering issues.

As for the general question around platforms with weaker memory models, AArch64 is not the first such platform that MSVC and Windows have been ported to. It is safe to assume that MSVC has a similar approach to GCC and Clang on memory reordering optimizations. [1] also gives some pointers on some MSVC specific knobs for working around the weaker memory model.

Also, would jcstress help root out these kinds of issues in Hotspot, or does that only test the code generated with the Interpreter/C1/C2? We run successfully jcstress in `tough` mode.

I hope this helps to answer your questions.

[1] https://docs.microsoft.com/en-us/cpp/build/common-visual-cpp-arm-migration-issues?view=vs-2019#volatile-keyword-default-behavior

--
Ludovic
________________________________________
From: Andrew Haley <aph at redhat.com>
Sent: Monday, July 13, 2020 01:36
To: David Holmes; Thomas Stüfe
Cc: Kim Barrett; Ludovic Henry; hotspot-runtime-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; openjdk-aarch64
Subject: Re: [aarch64-port-dev ] RFR(S): 8248657: Windows: strengthening in ThreadCritical regarding memory model

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.redhat.com%2F&data=02%7C01%7Cluhenry%40microsoft.com%7C382df232c9e14d02489b08d82707efb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302262326530322&sdata=4aWlLFQiA5WM8199fuDeMfFZoSyQzznGe9kwotVP2tk%3D&reserved=0>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkeybase.io%2Fandrewhaley&data=02%7C01%7Cluhenry%40microsoft.com%7C382df232c9e14d02489b08d82707efb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302262326530322&sdata=UiS3crdMoemJly%2BESLC%2F50noHZya9zArFenhHNVJ7C4%3D&reserved=0
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671