Memory ordering in C2

[David Holmes]

On 26/02/2014 1:41 AM, Lindenmaier, Goetz wrote:
> Hi,
>
>>  From what I've seen, C2 is enthusiastically emitting barrier nodes
>> around CompareAndSwap, so I'm not quite sure what this means.
> Yes, you are right ... that's again because we implement MemBArAcquire empty,
> but after the CompareAndSwap we need one, so we had to add it in the node ;)
> So same issue, distinguishing nodes would help!  The bad thing is that MemBarAcquire
> is implemented empty, that spoils the other uses.  If there is a way to avoid MemBarAcquire
> where it needs to be empty (after volatile load), then it can be implemented
> properly ...

I'm unclear what you mean by "needs to be empty" ??

David

> Best regards,
>    Goetz.
>
> -----Original Message-----
> From: Andrew Haley [mailto:aph at redhat.com]
> Sent: Dienstag, 25. Februar 2014 16:30
> To: Lindenmaier, Goetz; hotspot-dev Source Developers
> Subject: Re: Memory ordering in C2
>
> Hi,
>
> On 02/25/2014 03:20 PM, Lindenmaier, Goetz wrote:
>
>> We added a a few new node types in this change:
>> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/50fdb38839eb
>> This solved the issue that we implement MemBarAcquire empty.
>
> Ah yes.  Good, I can use that too.
>
>> But yes, we would appreciate further modularization in this direction.
>> We proposed similar stuff in this mail:
>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-February/013384.html
>
> Thanks.  I saw that at the time but didn't quite realize how similar
> it was to my own issues.
>
>> Actually, we would like more barrier nodes in some places (around
>> CompareAndSwap) because we issue sync instructions in those nodes.
>> If they are extra nodes, we can optimize them.  At other places, we
>> would like less ... ;)
>
>>From what I've seen, C2 is enthusiastically emitting barrier nodes
> around CompareAndSwap, so I'm not quite sure what this means.
>
>> And I guess x86 & friends, that always use empty nodes could profit, too.
>>
>> Further we would like to have explicit specification of the required
>> barriers in the nodes (Only one node, but listing the barriers
>> required (StoreStore | StoreLoad etc)).
>
> That would indeed be nice, but difficult.
>
> Andrew.
>