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

[Aleksey Shipilev]

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
> support_IRIW_for_not_multiple_copy_atomic_cpu 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>