RFR(M): 8080289: Intermediate writes in a loop not eliminated by optimizer (original) (raw)

Aleksey Shipilev aleksey.shipilev at oracle.com
Tue Jun 23 09:13:15 UTC 2015

On 06/23/2015 11:57 AM, Roland Westrelin wrote:

If I read the code correctly when supportIRIWfornotmultiplecopyatomiccpu is true we don’t add a membar after a volatile store so folding a store with previous ones would not be a correct optimization because it could remove volatile stores. This said the current code in StoreNode::Ideal() that folds back to back stores has the effect or reordering stores on different slices. So isn’t there a bug already?

Let's back up a bit. Short story. Given the program: volatile int y; int x; x = 1; y = 1; // volatile store x = 2; y = 2; // volatile store This transformation is correct: x = 1; x = 2; y = 2; // volatile store What about volatile int y; volatile int x; y=1 x=1 y=2 transformed to: x=1 y=2 ?

I think this is not allowed, since operations over "x" get tied up in the synchronization order. Here is the simplest counter-example:

volatile int y; volatile int x;

y = 1; | r1 = x; x = 1; | r2 = y; y = 2; |

(1, 0) -- forbidden, violates SO-PO consistency (seeing x=1 implies seeing y=1 in program order before it)

volatile int y; volatile int x;

... | r1 = x; x = 1; | r2 = y; y = 2; |

(1, 0) -- allowed by transformed program, oops.

(These cases are what jcstress sequential consistency tests are about)

Thanks, -Aleksey

-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150623/949cdbc0/signature.asc>

More information about the hotspot-compiler-dev mailing list