[aarch64-port-dev ] openjdk atomics

[Andrew Haley]

Hi,

On 02/11/2014 10:52 AM, Edward Nevill wrote:

> Does the following issue in the linux kernel to do with memory
> barriers across atomic operations affect us.
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-February/229588.html

Thanks.  This looks like it applies to us too.

> My guess is it is not well defined and we should put in the dmb to be sure.

It's worse than that because cmpxchg (AKA cas) is the primitive that's
used almost everywhere, and it needs a barrier at each end to make
sure that memory operations aren't speculated after the ldxr:

	dmb	ish		// Full barrier

1:	ldxr	%1, %2
	cmp	%1, %3
	b.ne	2f
	stxr	%w0, %4, %2
	cbnz	%w0, 1b
2:
	dmb	ish		// Full barrier

So, cmpxchg and cmpxchgw need to be changed to the above.  These
appear in macroAssembler and aarch64.ad.  C1_LIRAssembler's atomic_op
also needs fixing with two barriers for lir_xchg but only one for
lir_xadd.  I think that eden_allocate can stay as it is; it might be
that it doesn't even need barriers, but that's an optimization for
later.

It's unfortunate that we're going to be emitting unnecessary barriers,
but CAS seems to be the only primitive that C2 understands, presumably
because that's what SPARC and x86 do.  There are several cases where
we use CAS in hand-written code but could use a more efficient
sequence.

Andrew.