Mercurial > hg > truffle
comparison graal/com.oracle.max.cri/src/com/oracle/max/cri/intrinsics/MemoryBarriers.java @ 3733:e233f5660da4
Added Java files from Maxine project.
author | Thomas Wuerthinger <thomas.wuerthinger@oracle.com> |
---|---|
date | Sat, 17 Dec 2011 19:59:18 +0100 |
parents | |
children |
comparison
equal
deleted
inserted
replaced
3732:3e2e8b8abdaf | 3733:e233f5660da4 |
---|---|
1 /* | |
2 * Copyright (c) 2011, 2011, Oracle and/or its affiliates. All rights reserved. | |
3 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. | |
4 * | |
5 * This code is free software; you can redistribute it and/or modify it | |
6 * under the terms of the GNU General Public License version 2 only, as | |
7 * published by the Free Software Foundation. | |
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 com.oracle.max.cri.intrinsics; | |
24 | |
25 import static com.oracle.max.cri.intrinsics.IntrinsicIDs.*; | |
26 | |
27 import com.sun.max.annotate.*; | |
28 | |
29 /** | |
30 * Constants and intrinsic definition for memory barriers. | |
31 * | |
32 * The documentation for each constant is taken from Doug Lea's | |
33 * <a href="http://gee.cs.oswego.edu/dl/jmm/cookbook.html">The JSR-133 Cookbook for Compiler Writers</a>. | |
34 * <p> | |
35 * The {@code JMM_*} constants capture the memory barriers necessary to implement the Java Memory Model | |
36 * with respect to volatile field accesses. Their values are explained by this | |
37 * comment from templateTable_i486.cpp in the HotSpot source code: | |
38 * <pre> | |
39 * Volatile variables demand their effects be made known to all CPU's in | |
40 * order. Store buffers on most chips allow reads & writes to reorder; the | |
41 * JMM's ReadAfterWrite.java test fails in -Xint mode without some kind of | |
42 * memory barrier (i.e., it's not sufficient that the interpreter does not | |
43 * reorder volatile references, the hardware also must not reorder them). | |
44 * | |
45 * According to the new Java Memory Model (JMM): | |
46 * (1) All volatiles are serialized wrt to each other. | |
47 * ALSO reads & writes act as acquire & release, so: | |
48 * (2) A read cannot let unrelated NON-volatile memory refs that happen after | |
49 * the read float up to before the read. It's OK for non-volatile memory refs | |
50 * that happen before the volatile read to float down below it. | |
51 * (3) Similarly, a volatile write cannot let unrelated NON-volatile memory refs | |
52 * that happen BEFORE the write float down to after the write. It's OK for | |
53 * non-volatile memory refs that happen after the volatile write to float up | |
54 * before it. | |
55 * | |
56 * We only put in barriers around volatile refs (they are expensive), not | |
57 * _between_ memory refs (which would require us to track the flavor of the | |
58 * previous memory refs). Requirements (2) and (3) require some barriers | |
59 * before volatile stores and after volatile loads. These nearly cover | |
60 * requirement (1) but miss the volatile-store-volatile-load case. This final | |
61 * case is placed after volatile-stores although it could just as well go | |
62 * before volatile-loads. | |
63 * </pre> | |
64 */ | |
65 public class MemoryBarriers { | |
66 | |
67 /** | |
68 * The sequence {@code Load1; LoadLoad; Load2} ensures that {@code Load1}'s data are loaded before data accessed | |
69 * by {@code Load2} and all subsequent load instructions are loaded. In general, explicit {@code LoadLoad} | |
70 * barriers are needed on processors that perform speculative loads and/or out-of-order processing in which | |
71 * waiting load instructions can bypass waiting stores. On processors that guarantee to always preserve load | |
72 * ordering, these barriers amount to no-ops. | |
73 */ | |
74 public static final int LOAD_LOAD = 0x0001; | |
75 | |
76 /** | |
77 * The sequence {@code Load1; LoadStore; Store2} ensures that {@code Load1}'s data are loaded before all data | |
78 * associated with {@code Store2} and subsequent store instructions are flushed. {@code LoadStore} barriers are | |
79 * needed only on those out-of-order processors in which waiting store instructions can bypass loads. | |
80 */ | |
81 public static final int LOAD_STORE = 0x0002; | |
82 | |
83 /** | |
84 * The sequence {@code Store1; StoreLoad; Load2} ensures that {@code Store1}'s data are made visible to other | |
85 * processors (i.e., flushed to main memory) before data accessed by {@code Load2} and all subsequent load | |
86 * instructions are loaded. {@code StoreLoad} barriers protect against a subsequent load incorrectly using | |
87 * {@code Store1}'s data value rather than that from a more recent store to the same location performed by a | |
88 * different processor. Because of this, on the processors discussed below, a {@code StoreLoad} is strictly | |
89 * necessary only for separating stores from subsequent loads of the same location(s) as were stored before the | |
90 * barrier. {@code StoreLoad} barriers are needed on nearly all recent multiprocessors, and are usually the most | |
91 * expensive kind. Part of the reason they are expensive is that they must disable mechanisms that ordinarily | |
92 * bypass cache to satisfy loads from write-buffers. This might be implemented by letting the buffer fully | |
93 * flush, among other possible stalls. | |
94 */ | |
95 public static final int STORE_LOAD = 0x0004; | |
96 | |
97 /** | |
98 * The sequence {@code Store1; StoreStore; Store2} ensures that {@code Store1}'s data are visible to other | |
99 * processors (i.e., flushed to memory) before the data associated with {@code Store2} and all subsequent store | |
100 * instructions. In general, {@code StoreStore} barriers are needed on processors that do not otherwise | |
101 * guarantee strict ordering of flushes from write buffers and/or caches to other processors or main memory. | |
102 */ | |
103 public static final int STORE_STORE = 0x0008; | |
104 | |
105 public static final int JMM_PRE_VOLATILE_WRITE = LOAD_STORE | STORE_STORE; | |
106 public static final int JMM_POST_VOLATILE_WRITE = STORE_LOAD | STORE_STORE; | |
107 public static final int JMM_PRE_VOLATILE_READ = 0; | |
108 public static final int JMM_POST_VOLATILE_READ = LOAD_LOAD | LOAD_STORE; | |
109 | |
110 | |
111 /** | |
112 * @see IntrinsicIDs#MEMBAR | |
113 */ | |
114 @INTRINSIC(MEMBAR) | |
115 public static native void barrier(@INTRINSIC.Constant int barrierSpec); | |
116 | |
117 | |
118 public static String barriersString(int barriers) { | |
119 StringBuilder sb = new StringBuilder(); | |
120 sb.append((barriers & LOAD_LOAD) != 0 ? "LOAD_LOAD " : ""); | |
121 sb.append((barriers & LOAD_STORE) != 0 ? "LOAD_STORE " : ""); | |
122 sb.append((barriers & STORE_LOAD) != 0 ? "STORE_LOAD " : ""); | |
123 sb.append((barriers & STORE_STORE) != 0 ? "STORE_STORE " : ""); | |
124 return sb.toString().trim(); | |
125 } | |
126 } |