Memory ordering in C2

[Lindenmaier, Goetz]

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 ...

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.