Memory ordering in C2 (original) (raw)

Andrew Haley aph at redhat.com
Tue Feb 25 06:11:21 PST 2014

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