RFR (S): 8153751: Windows Atomic and OrderAccess are not emitting explicit compiler barriers

[Erik Österlund]

Hi,

Bug: https://bugs.openjdk.java.net/browse/JDK-8153751
Webrev: http://cr.openjdk.java.net/~eosterlund/8153751/webrev.00/

It turns out that on Windows, compiler barriers are not used for 
Atomic:: code and some code in OrderAccess. It is assumed that the 
non-volatile accesses will not be reordered across __asm statements, as 
the current memory model should prevent. But I have not found any 
guarantees that this is the case for __asm.

The closest source I could find is the documentation for the 
MemoryBarrier macro that uses an __asm statement to produce a hardware 
membar. The documentation says the following: "Creates a hardware memory 
barrier (fence) that prevents the CPU from re-ordering read and write 
operations. It may also prevent the compiler from re-ordering read and 
write operations."

Note the "MAY" prevent compiler reordering. (*facepalm*) This sounds to 
me like __asm really does not guarantee compiler reordering across __asm 
at all.

A suspected victim of this reordering is here: 
https://bugs.openjdk.java.net/browse/JDK-8033545

To make the use of these classes more safe, I propose to simply add 
explicit compiler barriers in this windows code. It should not make any 
difference, as I am only enforcing compiler reordering rules that should 
already hold.

This small patch fixes this. The only thing to note is that the __asm 
statements that put things in %eax and avoid returning anything.

Testing: JPRT

Thanks,
/Erik