JDK-8028515 : PPC64 (part 113.2): opto: Introduce LoadFence/StoreFence.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: port-stage-ppc-aix
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • CPU: ppc
  • Submitted: 2013-11-18
  • Updated: 2014-07-29
  • Resolved: 2013-11-27
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 8 JDK 9 Other
8u20Fixed 9Fixed port-stage-ppc-aixFixed
The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory ordering in various places. Some order a certain load/store with other operations. inline_unsafe_fence() inserts MemBars that do not correspont to a memory operation. So far, the same nodes were used. 

This change introduces MemBarFenceAcquire/Release to use where no dedicated load/store is ordered. With this change, these nodes can be matched differently, what is needed on PPC64.


This is preparation for PPC64 integration: http://openjdk.java.net/jeps/175 
This and following ppc64 changes will go into staging repository first and tested there: http://hg.openjdk.java.net/ppc-aix-port/stage/
Extend Load and Store nodes to know about memory ordering. 

Names were changed again to LoadFence/StoreFence I updated subject. Fix changeset will use new subject.

During review, we decided to use other names for the nodes. I updated title and description of this bug accordingly (before: MemBarAcquire/ReleaseWide).

Seems better to me to introduce a "fence" node rather than continue the misuse of the acquire/release nomenclature when there is no associated load or store.