As reported on:
http://stackoverflow.com/questions/10620680/why-volatile-in-java-5-doesnt-synchronize-cached-copies-of-variables-with-main
and discussed on:
http://cs.oswego.edu/pipermail/concurrency-interest/2012-May/009440.html
and
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-May/007704.html
The following test program reports "Error" where under the Java Memory Model rules it never should:
public class VolatileBug {
volatile static private int a;
static private int b;
public static void main(String [] args) throws Exception {
for (int i = 0; i < 100; i++) {
new Thread() {
@Override
public void run() {
int tt = b; // makes the jvm cache the value of b
while (a==0) {
}
if (b == 0) {
System.out.println("error");
}
}
}.start();
}
b = 1;
a = 1;
}
}
Investigation shows the problem is in the GlobalValueNumbering code where the load of the volatile field doesn't kill the prevous load of a non-volatile field, resulting in the old value incorrectly being re-used after the volatile field is read.
http://stackoverflow.com/questions/10620680/why-volatile-in-java-5-doesnt-synchronize-cached-copies-of-variables-with-main
and discussed on:
http://cs.oswego.edu/pipermail/concurrency-interest/2012-May/009440.html
and
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-May/007704.html
The following test program reports "Error" where under the Java Memory Model rules it never should:
public class VolatileBug {
volatile static private int a;
static private int b;
public static void main(String [] args) throws Exception {
for (int i = 0; i < 100; i++) {
new Thread() {
@Override
public void run() {
int tt = b; // makes the jvm cache the value of b
while (a==0) {
}
if (b == 0) {
System.out.println("error");
}
}
}.start();
}
b = 1;
a = 1;
}
}
Investigation shows the problem is in the GlobalValueNumbering code where the load of the volatile field doesn't kill the prevous load of a non-volatile field, resulting in the old value incorrectly being re-used after the volatile field is read.
- duplicates
-
JDK-7170145 C1 doesn't respect the JMM with volatile field loads
- Closed
- relates to
-
JDK-6756768 C1 generates invalid code
- Resolved