JDK-8151020 : [TESTBUG] UnsafeGetStableArrayElement::testL_* fail intermittently
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-03-02
  • Updated: 2020-09-01
  • Resolved: 2016-03-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b110Fixed
Related Reports
Relates :  
JDK-8151137 - [TESTBUG] UnsafeGetStableArrayElement.java still fails with "(assert failed: 0 != 0)"
Relates :  
JDK-8150186 - Folding mismatched accesses with @Stable is incorrect
Relates :  
JDK-8150543 - Mismatched access detection is inaccurate
Relates :  
JDK-8151138 - [TESTBUG] UnsafeGetStableArrayElement.java still fails with "(assert failed: 0 != 0)"
Description
The test compiler/unsafe/UnsafeGetStableArrayElement.java fails with:

----------System.out:(1/40)----------
CompileCommand: dontinline *Test.test*
----------System.err:(21/1270)----------
java.lang.RuntimeException: (assert failed: 0 != 0)
	at jdk.test.lib.Asserts.error(Asserts.java:447)
	at jdk.test.lib.Asserts.assertTrue(Asserts.java:374)
	at jdk.test.lib.Asserts.assertFalse(Asserts.java:353)
	at jdk.test.lib.Asserts.assertNotEquals(Asserts.java:292)
	at jdk.test.lib.Asserts.assertNotEquals(Asserts.java:275)
	at jdk.test.lib.Asserts.assertNE(Asserts.java:257)
	at UnsafeGetStableArrayElement.run(UnsafeGetStableArrayElement.java:201)
	at UnsafeGetStableArrayElement.testMismatched(UnsafeGetStableArrayElement.java:212)
	at UnsafeGetStableArrayElement.main(UnsafeGetStableArrayElement.java:299)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:520)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92)
	at java.lang.Thread.run(Thread.java:804)

JavaTest Message: Test threw exception: java.lang.RuntimeException: (assert failed: 0 != 0)
JavaTest Message: shutting down test
Comments
False alarm. Forgot to specify -server. But I spotted another issue (test bug this time): testMismatched(Test::testL_Z, Test::changeL); testMismatched(Test::testL_B, Test::changeL); testMismatched(Test::testL_S, Test::changeL); testMismatched(Test::testL_C, Test::changeL); testMismatched(Test::testL_I, Test::changeL); testMismatched(Test::testL_J, Test::changeL); testMismatched(Test::testL_F, Test::changeL); testMismatched(Test::testL_D, Test::changeL); testMatched( Test::testL_L, Test::changeL); OOPs can be anything, so there's no guarantee that the location we are reading from doesn't contain 0. It happens rarely, so the test can fail intermittently.
02-03-2016
Thank you, Vladimir!
02-03-2016
I was able to reproduce it w/ latest binaries on windows-x86. Looking into the failure.
02-03-2016
This test was recently added by JDK-8150186 and was updated by JDK-8150543. I suspect the issue to be solved by JDK-8150543. I'll assign the issue to myself until I can confirm/deny that.
02-03-2016