comparison graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/MemoryBarriers.java @ 14906:f3a5036cc13c

javadoc fixes javadoc has become stricter in jdk8
author Bernhard Urban <bernhard.urban@jku.at>
date Mon, 31 Mar 2014 20:51:09 +0200
parents 5e3d1a68664e
children f57d86eb036f
comparison
equal deleted inserted replaced
14905:b7afc71535d3 14906:f3a5036cc13c
22 */ 22 */
23 package com.oracle.graal.api.code; 23 package com.oracle.graal.api.code;
24 24
25 /** 25 /**
26 * Constants and intrinsic definition for memory barriers. 26 * Constants and intrinsic definition for memory barriers.
27 * 27 *
28 * The documentation for each constant is taken from Doug Lea's <a 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 29 * href="http://gee.cs.oswego.edu/dl/jmm/cookbook.html">The JSR-133 Cookbook for Compiler
30 * Writers</a>. 30 * Writers</a>.
31 * <p> 31 * <p>
32 * The {@code JMM_*} constants capture the memory barriers necessary to implement the Java Memory 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 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: 34 * templateTable_i486.cpp in the HotSpot source code:
35 * 35 *
36 * <pre> 36 * <pre>
37 * Volatile variables demand their effects be made known to all CPU's in 37 * Volatile variables demand their effects be made known to all CPU's in
38 * order. Store buffers on most chips allow reads & writes to reorder; the 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 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 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). 41 * reorder volatile references, the hardware also must not reorder them).
42 * 42 *
43 * According to the new Java Memory Model (JMM): 43 * According to the new Java Memory Model (JMM):
44 * (1) All volatiles are serialized wrt to each other. 44 * (1) All volatiles are serialized wrt to each other.
45 * ALSO reads & writes act as acquire & release, so: 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 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 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. 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 49 * (3) Similarly, a volatile write cannot let unrelated NON-volatile memory refs
50 * that happen BEFORE the write float down to after the write. It's OK for 50 * that happen BEFORE the write float down to after the write. It's OK for