Memory ordering in C2 (original) (raw)

David Holmes david.holmes at oracle.com
Tue Feb 25 20:32:48 PST 2014


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.



More information about the hotspot-dev mailing list