8  *
   9  * This code is distributed in the hope that it will be useful, but WITHOUT
  10  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
  11  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
  12  * version 2 for more details (a copy is included in the LICENSE file that
  13  * accompanied this code).
  14  *
  15  * You should have received a copy of the GNU General Public License version
  16  * 2 along with this work; if not, write to the Free Software Foundation,
  17  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  18  *
  19  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
  20  * or visit www.oracle.com if you need additional information or have any
  21  * questions.
  22  */
  23 package jdk.vm.ci.code;
  24 
  25 /**
  26  * Constants and intrinsic definition for memory barriers.
  27  *
  28  * The documentation for each constant is taken from Doug Lea's <a
  29  * href="http://gee.cs.oswego.edu/dl/jmm/cookbook.html">The JSR-133 Cookbook for Compiler
  30  * Writers</a>.
  31  * <p>
  32  * The {@code JMM_*} constants capture the memory barriers necessary to implement the Java Memory
  33  * Model with respect to volatile field accesses. Their values are explained by this comment from
  34  * templateTable_i486.cpp in the HotSpot source code:
  35  *
  36  * <pre>
  37  * Volatile variables demand their effects be made known to all CPU's in
  38  * order.  Store buffers on most chips allow reads &amp; writes to reorder; the
  39  * JMM's ReadAfterWrite.java test fails in -Xint mode without some kind of
  40  * memory barrier (i.e., it's not sufficient that the interpreter does not
  41  * reorder volatile references, the hardware also must not reorder them).
  42  *
  43  * According to the new Java Memory Model (JMM):
  44  * (1) All volatiles are serialized wrt to each other.
  45  * ALSO reads &amp; writes act as acquire &amp; release, so:
  46  * (2) A read cannot let unrelated NON-volatile memory refs that happen after
  47  * the read float up to before the read.  It's OK for non-volatile memory refs
  48  * that happen before the volatile read to float down below it.
  49  * (3) Similarly, a volatile write cannot let unrelated NON-volatile memory refs

   8  *
   9  * This code is distributed in the hope that it will be useful, but WITHOUT
  10  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
  11  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
  12  * version 2 for more details (a copy is included in the LICENSE file that
  13  * accompanied this code).
  14  *
  15  * You should have received a copy of the GNU General Public License version
  16  * 2 along with this work; if not, write to the Free Software Foundation,
  17  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  18  *
  19  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
  20  * or visit www.oracle.com if you need additional information or have any
  21  * questions.
  22  */
  23 package jdk.vm.ci.code;
  24 
  25 /**
  26  * Constants and intrinsic definition for memory barriers.
  27  *
  28  * The documentation for each constant is taken from Doug Lea's
  29  * <a href="http://gee.cs.oswego.edu/dl/jmm/cookbook.html">The JSR-133 Cookbook for Compiler
  30  * Writers</a>.
  31  * <p>
  32  * The {@code JMM_*} constants capture the memory barriers necessary to implement the Java Memory
  33  * Model with respect to volatile field accesses. Their values are explained by this comment from
  34  * templateTable_i486.cpp in the HotSpot source code:
  35  *
  36  * <pre>
  37  * Volatile variables demand their effects be made known to all CPU's in
  38  * order.  Store buffers on most chips allow reads &amp; writes to reorder; the
  39  * JMM's ReadAfterWrite.java test fails in -Xint mode without some kind of
  40  * memory barrier (i.e., it's not sufficient that the interpreter does not
  41  * reorder volatile references, the hardware also must not reorder them).
  42  *
  43  * According to the new Java Memory Model (JMM):
  44  * (1) All volatiles are serialized wrt to each other.
  45  * ALSO reads &amp; writes act as acquire &amp; release, so:
  46  * (2) A read cannot let unrelated NON-volatile memory refs that happen after
  47  * the read float up to before the read.  It's OK for non-volatile memory refs
  48  * that happen before the volatile read to float down below it.
  49  * (3) Similarly, a volatile write cannot let unrelated NON-volatile memory refs