Memory ordering in C2 (original) (raw)

Andrew Haley aph at redhat.com
Tue Feb 25 07:30:17 PST 2014

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.

More information about the hotspot-dev mailing list