JDK-8209420 : Track membars for volatile accesses so they can be properly optimized
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8-aarch64,11,12
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-08-13
  • Updated: 2021-06-11
  • Resolved: 2018-08-22
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 11 JDK 12 JDK 8 Other
11.0.5Fixed 12 b09Fixed 8u301Fixed openjdk8u292Fixed
Related Reports
Blocks :  
JDK-8210389 - C2: assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc
Relates :  
JDK-8211233 - MemBarNode::trailing_membar() and MemBarNode::leading_membar() need to handle dying subgraphs better
Relates :  
JDK-8257192 - Integrate AArch64 JIT port into 8u
Relates :  
JDK-8214857 - "bad trailing membar" assert failure at memnode.cpp:3220
Description
Aarch64 emits a single instruction for volatile accesses that include the required memory barriers. For this to work properly the aarch64 backend has to locate membars that go with a memory access to elide them. This is currently implemented with some complicated pattern matching that has proven fragile and painful to maintain. This change introduces a new and robust logic to locate membars and memory accesses for volatile accesses.
Comments
Fix Request 11u What: Original patch applies to jdk11u cleanly Why: Review thread: https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-August/007870.html As discussed in the thread, we are witnessing real-world volatile access inconsistency bugs on our Kunpeng 64/128 core aarch64 server platform. The same issue is there in jdk11u in theory. As pointed out by adinn, this patch would be worth backporting /even without/ the problems we have encountered because it significantly reduces complexity. Testing: Run tier1 test with 11u aarch64 release build, no new failure found Passed Jcstress test with 11u aarch64 release build Risk: The original patch was committed to jdk13 about one year ago, risk should be low
14-08-2019
I think we should backport this to aarch64-8u repo & 11u repo. We are seeing real world bugs on the aarch64 platform because of failure of pattern matching.
06-08-2019