Memory ordering in C2 (original) (raw)

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Tue Feb 25 07:20:25 PST 2014

Hi,

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.

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

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

Best regards, Goetz.

-----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Andrew Haley Sent: Dienstag, 25. Februar 2014 15:11 To: hotspot-dev Source Developers Subject: Memory ordering in C2

This is related to the discussion about memory ordering raised by the PPC team, but it's not the same.

Aarch64 has a weakly-ordered memory system, so needs memory barriers. It also has load acquire and store release instructions, and I would quite like to use these for volatile fields. I have already made sure that these instructions have the correct semantics.

However, I can't do that in the obvious way (by generating ld.acq and st.rel and) defining empty versions of MemBarAcquire and MemBarRelease in the ADfile because MemBarRelease isn't used only for volatile fields. It's also used for constructor barriers, and I need those.

A related problem is that C2 sprinkles these quite expensive barriers in a number of other places, particularly around locks and atomic operations. This is painful because the atomic operations already have a standard efficient sequence of instructions that has the required semantics.

It seems to me that the back end needs to have far more control over what barriers are emitted, and when. I would like to be able to control all of the explicit barriers in a machine-dependent way. A good start would be if I could disable barriers around locks without affecting other places that really need them. I don't want to have to scribble #ifdef AARCH64 all over the machine-independent code.

I suppose the easiest way to do this would be to add a few new barrier types.

Thoughts?

Thank you, Andrew.

More information about the hotspot-dev mailing list