Problems with compiler/unsafe/JdkInternalMiscUnsafeAccessTest on PowerPC

Volker Simonis volker.simonis at
Fri Apr 29 13:53:20 UTC 2016

Hi Aleksey,

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


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

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

Martin & Volker

More information about the hotspot-compiler-dev mailing list