Problems with compiler/unsafe/JdkInternalMiscUnsafeAccessTest on PowerPC

[Doerr, Martin]

Hi Aleksey,

I have used the following test block on ppc64le. More than 2 attempts in the single-threaded test were never observed.
So it would be interesting to report it somehow if that happens.

        {
            int attempts = 0;
            boolean r;
            do {
              attempts++;
              r = UNSAFE.weakCompareAndSwapInt(base, offset, 1, 2);
            } while (!r && attempts < 10);
            if (attempts > 2) {
              reportMessage(attempts, "weakCompareAndSwap int 1 -> 2");
            }
            int x = UNSAFE.getInt(base, offset);
            assertEquals(x, 2, "weakCompareAndSwap int value 1 -> 2");
        }

Is this what you mean by simple weakCAS test prototype?

Best regards,
Martin


-----Original Message-----
From: Aleksey Shipilev [mailto:aleksey.shipilev at oracle.com] 
Sent: Freitag, 29. April 2016 16:05
To: Volker Simonis <volker.simonis at gmail.com>; hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
Cc: Doerr, Martin <martin.doerr at sap.com>
Subject: Re: Problems with compiler/unsafe/JdkInternalMiscUnsafeAccessTest on PowerPC

* PGP Signature not checked

Hi Volker,

On 04/29/2016 04:53 PM, Volker Simonis wrote:
> The problem is that a weakComapreAndSwap may spuriously fail, but the
> tests assume that it will always succeed. On Power we saw for example
> the following kind of failures:
> 
> test JdkInternalMiscUnsafeAccessTestInt.testArray(): failure
> java.lang.AssertionError: weakCompareAndSwapRelease int expected
> [true] but found [false]
>         at org.testng.Assert.fail(Assert.java:94)
>         at org.testng.Assert.failNotEquals(Assert.java:494)
>         at org.testng.Assert.assertEquals(Assert.java:123)
>         at org.testng.Assert.assertEquals(Assert.java:286)
>         at JdkInternalMiscUnsafeAccessTestInt.testAccess(JdkInternalMiscUnsafeAccessTestInt.java:269)
>         at JdkInternalMiscUnsafeAccessTestInt.testArray(JdkInternalMiscUnsafeAccessTestInt.java:109)
> 
> From our understanding of the weakComapreAndSwap semantics it is
> however perfectly legal that the weakComapreAndSwap fails and the old
> values remain in place.

Ah, oops, indeed! The test is too strong, and it just happens to work on
x86. AArch64 should fail the same, once intrinsics are there.
jdk/test/java/lang/invoke/VarHandles should fail too, so it deserves a
global testbug fix.

Can you prototype and test a simple weakCAS/CAE test on the POWER? We
can then propagate the test shape to other tests with:
  https://bugs.openjdk.java.net/browse/JDK-8155739


> We would propose to run the weakComapreAndSwap in a loop in the test
> until it succeeds and only check for the correct value in memory
> afterwards. We could also log the number of retry attempts until the
> weakComapreAndSwap succeeds into the .jtr file.

Yes, looping is better for the tests.


> As far as we saw, all the regression tests are single threaded. Are
> there any multi-threaded tests available which stress the new Unsafe
> intrinsics (i.e. in the way this was previously done by the Java
> Concurrency Torture tests which verified that only valid combinations
> of reads were observed).

Yes, we have the jcstress tests pending for VarHandles, but they are not
yet committed to jcstress.

Thanks,
-Aleksey



* Signature checking is off by policy