Seeing error in one test on ARM: org.openjdk.jcstress.tests.volatiles.ReadTwiceOverVolatileReadTest

[White, Derek]

OK, I'm trying to get all of the issues loaded into my head. If anyone can confirm, deny, or shed light on the following I would be very thankful!

Looking at actor2(), as if compiled by C1:

  	ldr     w10, [x1,#12] 	// w10 = x;
	add     x2, x1, #0x10
	ldar    w11, [x2]		// w11 = y;
	ldr     w12, [x1,#12] 	// w12 = x;
Result:
w10 = 1
w11 = 0
w12 = 0

1)  One explanation for this is that the load of w12 completed out-of-order before the load of w10, so it saw the initial order.
But this seems to violate the requirement that:
" Two reads to the same address by the same observer are observed in program order by all observers within
the shareability domain of the memory address being accessed." B2.7.2, ARM ARM v8.

This requirement is independent of the LDAR of w11.

2) The LDAR adds the additional requirement (paraphrased by cancelling out text of shareability domains):
"For a Load-Acquire, observers observe accesses in the following order:
  1. The read caused by the Load-Acquire.
  2. Reads and writes caused by loads and stores that appear in program order after the Load-Acquire requires that the observer observes the access." B2.7.3.

There is so much verbiage in the original text, but this seems to imply that the load into w12 can't move above the ldar of w11. But this restriction by itself doesn't prevent an earlier load being delayed after the ldar. So if the 1st and 3rd  loads had different source virtual addresses then the load of w10 could have been delayed after the load of w12.

3) The C1 code sequences of actor1() and actor2() are nearly exactly the litmus test described in K10.2.1 (load-acquire/store-release), while the C2 code sequences (using dmb) are about the same as the litmus test in K10.6.1.

Thanks,

 -Derek


-----Original Message-----
From: Aleksey Shipilev [mailto:shade at redhat.com] 
Sent: Thursday, February 23, 2017 9:36 AM
To: White, Derek <Derek.White at cavium.com>; jcstress-dev at openjdk.java.net
Subject: Re: Seeing error in one test on ARM: org.openjdk.jcstress.tests.volatiles.ReadTwiceOverVolatileReadTest

On 02/23/2017 03:32 PM, White, Derek wrote:
> I want to nail down the nearly obvious, because the next level get 
> tricky to me real fast.
> 
> The result (1, 0, 0) n this test means that actor2() read and stored x 
> as 1, read and stored y as 0 (so far, so good), and read and stored X 
> as 0. Is this correct?

Yes. And JMM actually allows this result for plain memory ops, hence the test grading fix. But it is suspicious to see this behavior on the actual hardware, because hardware is supposed to exhibit "coherency": a single modification order for a particular memory location. Reading x:1, and then x:0 is the evidence of coherency violation. See JMMSample_03 for more discussion.

Thanks,
-Aleksey