JDK-8198950 : AArch64: org.openjdk.jcstress.tests.varhandles.DekkerTest fails
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 10
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: aarch64
  • Submitted: 2018-03-02
  • Updated: 2018-04-19
  • Resolved: 2018-03-07
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 10 JDK 11
10 b46Fixed 11Fixed
Related Reports
Duplicate :  
JDK-8199249 - AArch64: org.openjdk.jcstress.tests.varhandles.DekkerTest fails
Relates :  
JDK-8181211 - C2: Use profiling data to optimize on/off heap unsafe accesses
Description
The DekkerTest in latest jcstress fails with a lot of 0, 0 states (please refer attached test result).

The build on tag "JDK10-b20" doesn't have this failure. And later-on build has this failure (included current master).

A simple test class extracted from jcstress DekkerTest is attached (DekkerVarTest.java). This class also shows such failure.
Comments
hgupdate HG Updates added a comment - 10 minutes ago URL: http://hg.openjdk.java.net/jdk/jdk10/rev/6fa770f9f8ab User: adinn Date: 2018-03-07 18:02:52 +0000 Copied the hgupdater notification here for any automated bug DB searchers.
07-03-2018
Removed 'Fix Version' 11. This JIRA instance uses singleton 'Fix Version' values. When the fix is pushed to jdk/jdk, a backport will be auto-created. Update: The push happened before I was able to fix the 'Fix Version' field so we ended up with two backports. I've resolved this bug ID as the fixed in '10' version and closed the errant '10' backport as a duplicate of this bug.
07-03-2018
Fix request approved
07-03-2018
Fix request Importance: This fix is critical because without it the semantics of volatile loads on AArch64 are not correctly implemented in C2 code. What is changed: The optimization made in JDK-8181211 to allow Load nodes to float has been partially reversed in the case where a Load node is created for a volatile field load. The reversion reinstates the status quo before that patch in this case. Since the optimization is not appropriate for a volatile load (the Load node cannot float because it is pinned in the memory hierarchy) this will not lose the benefit of the optimization since it only applies for the non-volatile case. Risk: The patch generates IR which was processed correctly before this change. The identical IR can be generated in cases where the load cannot be optimized for other reasons. So, there is no significant danger that this will cause any errors or regressions. Testing: On AArch64: this fixes the jcstress test (Dekker test) that was broken and does not cause any other jcstress tests to fail. It also causes no regressions in the jtreg tests for jdk tier1 and hotspot compiler On x86_64: the patch has been posted to the submit repo for checking. This test is still running.
06-03-2018
n.b. The submit repo job for this patch completed without any problems.
06-03-2018
Andrew, thanks for your fix!
06-03-2018
Hi Mikael, I would like to fix this with a change to shared code. I have just posted an RFR to jdk-dev and aarch64-dev explaining why and what the alternatives are: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-March/030523.html
06-03-2018
[~adinn] I'm trying to understand the impact on other platforms etc.: do you expect the fix to require changes to aarch64 specific code only, or are changes needed to other/shared code as well?
05-03-2018
Thanks, Andrew!
05-03-2018
Hi Tobias This is indeed a critical bug as it affects memory consistency for volatile varhandle operations. I have identified what broke the AArch64 code and have a patch which I believe fixes the problem. I'll post an RFR as soon as possible (I need to run the jcstress tests to be sure it doesn't have any unforeseen consequences). I will be sure to follow the fix request process once I have the patch tested and reviewed.
02-03-2018
Hi Zhongwei, please note that we are very late in the JDK 10 release: http://openjdk.java.net/projects/jdk/10/ If this bug is critical and needs to be fixed in JDK 10, please request approval according to: http://openjdk.java.net/projects/jdk/10/fix-request-process Otherwise, please defer to JDK 11: http://openjdk.java.net/projects/jdk/10/bug-deferral-process
02-03-2018