Memory ordering in C2

[Lindenmaier, Goetz]

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.