Problems with compiler/unsafe/JdkInternalMiscUnsafeAccessTest on PowerPC

Doerr, Martin martin.doerr at
Fri Apr 29 14:46:18 UTC 2016

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 {
              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,

-----Original Message-----
From: Aleksey Shipilev [mailto:aleksey.shipilev at] 
Sent: Freitag, 29. April 2016 16:05
To: Volker Simonis <volker.simonis at>; hotspot compiler <hotspot-compiler-dev at>
Cc: Doerr, Martin <martin.doerr at>
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
>         at org.testng.Assert.failNotEquals(
>         at org.testng.Assert.assertEquals(
>         at org.testng.Assert.assertEquals(
>         at JdkInternalMiscUnsafeAccessTestInt.testAccess(
>         at JdkInternalMiscUnsafeAccessTestInt.testArray(
> 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:

> 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.


* Signature checking is off by policy

More information about the hotspot-compiler-dev mailing list