Problems with compiler/unsafe/JdkInternalMiscUnsafeAccessTest on PowerPC

[Aleksey Shipilev]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160429/b4541bc4/signature.asc>