Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-7170319

Bug in GVN code in C1 breaks Java volatile semantics

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: P2 P2
    • hs24
    • 6
    • hotspot
    • None
    • 6
    • generic
    • generic

      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.

            Unassigned Unassigned
            dholmes David Holmes
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: