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

[Erik Osterlund]

Hi David,

Thanks for helping with this. Much appreciated! :)

/Erik

> On 16 apr. 2016, at 11:04, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Erik,
> 
> Still catching up on vacation email backlog but I will review this asap.
> 
> I see no one else has been game to step in yet :)
> 
> David
> 
>> On 8/04/2016 7:00 PM, Erik Österlund wrote:
>> 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