Problems with compiler/unsafe/JdkInternalMiscUnsafeAccessTest on PowerPC

[Volker Simonis]

Hi Aleksey,

while implementing the new intrinsics for jdk.internal.misc.Unsafe on
PowerPC we encountered problems with the following weakCompareAndSwap
tests:

compiler/unsafe/JdkInternalMiscUnsafeAccessTestInt.java
compiler/unsafe/JdkInternalMiscUnsafeAccessTestLong.java

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.

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.

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

Regards,
Martin & Volker