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

[Roland Westrelin]

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

What about

volatile int y;
volatile int x;

y=1
x=1
y=2

transformed to:

x=1
y=2

?

Roland.


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