JDK-8024921 : PPC64 (part 113): Extend Load and Store nodes to know about memory ordering.
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: port-stage-ppc-aix
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2013-09-17
  • Updated: 2014-08-12
  • Resolved: 2013-11-15
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
Related Reports
Relates :  
JDK-8054927 - Missing MemNode::acquire ordering in some volatile Load nodes
Relates :  
JDK-7143664 - Clean up OrderAccess implementations and usage
Description
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.

http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/df79d76c17ab/ppc_patches/0113_opto-Extend_Load_and_Store_nodes_to_know_about_memory_ordering.patch


Some platforms support special load/store intsturctions to do memory ordering. These can be cheaper than a normal load/store instruction followed by an according memory barrier instruction. E.g., IA64 has ld.acq and st.rel, and PPC has the ld-twi-isync combination that is better than 'ld lwsync'.

HotSpots C2 inserts MemBarAcquire and MemBarRelease nodes into the IR if memory ordering is needed for a load/store operation. This is not well suited to use above described load/store instructions.

This change extends the load/store nodes of the IR by a field that indicates whether the load/store should do an acquire/release. The field is either set to 'unordered', if the node may be reordered with others, or to 'acquire' for Loads and 'release' for Stores.  Checking for this field in the matcher allows to issue the proper operation.
If a platform does so, MemBarAcquire and MemBarRelease can be implemented empty, i.e., they basically serve to avoid reordering by the c2 compiler.

This change also removes default parameters from the affected load/store factory methods. Maintaining this change has shown very error prone if the defaults for the new field are ::unordered. If the default would be ::acquire/::release this would be safe, but then most places would need the parameter, anyways.
Comments
8-pool is an invalid affects version. Set 8 and hs25.
12-11-2013
Also see JDK-7143664.
11-10-2013
This needs to be considered very carefully. The only time C2 needs to be concerned with memory ordering is for Java volatiles and in that case there are both atomicity and ordering issues to consider. In addition we have to ensure that the low level load.acq and st.rel instructions provide the correct semantics to implement volatile variables. Rather than change the kind of nodes I would have expected that the actual code generation would combine the load+membarAcquire nodes into the relevant ld.acq instruction if applicable!
11-10-2013