Mercurial > hg > truffle
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 & 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 & writes act as acquire & 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 |