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

Aleksey Shipilev aleksey.shipilev at oracle.com
Tue Jun 23 08:43:54 UTC 2015

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

http://gee.cs.oswego.edu/dl/jmm/cookbook.html

it’s allowed to reorder normal stores with normal stores If we can guarantee that all passed stores are normal (I assume we will have barriers otherwise in between) then I agree. 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

...since it does not introduce non-SC behaviors. Removing volatile ops (e.g. as the result of coalescing) is fine, as long as you don't introduce new behaviors. See also, JSR133 Cookbook, "Removing Barriers", StoreLoad -> no volatile loads -> StoreLoad example.

Long story. Analyze the results of this program:

volatile int y;
         int x;

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

Possible outcomes: (0, 0) -- allowed, initial values (0, 1) -- allowed, racy read of "x" (0, 2) -- allowed, racy read of "x" (1, 0) -- forbidden, violates HB consistency (1, 1) -- allowed, last read of "x" in HB (1, 2) -- allowed, racy read of "x" (2, 0) -- forbidden, violates HB consistency (2, 1) -- forbidden, violates HB consistency (2, 2) -- allowed, last read of "x" in HB

Modified program:

volatile int y;
         int x;

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

Possible outcomes: (0, 0) -- allowed, initial values (0, 1) -- allowed, racy read of "x" (0, 2) -- allowed, racy read of "x" (2, 0) -- forbidden, violates HB consistency (2, 1) -- forbidden, violates HB consistency (2, 2) -- allowed, last read of "x" in HB

Here, modified program dropped the outcomes (1, *), but it does not start to allow other outcomes. The trick is that, in memory model sense, "allowed" does not mean "should be present".

BTW, jcstress has the sequential consistency tests for volatiles [1], it makes sense to run it if you touch read/write coalescing code. (Or not, it would be running in VM testing anyway).

Thanks, -Aleksey

[1] $ hg clone http://hg.openjdk.java.net/code-tools/jcstress/ jcstress $ cd jcstress/ $ mvn clean install -pl tests-generated -am $ java -jar tests-generated/target/jcstress.jar -t seqcst

-------------- 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/13ee50ae/signature.asc>

More information about the hotspot-compiler-dev mailing list