< prev index next >

src/share/vm/runtime/orderAccess.hpp

Print this page


   1 /*
   2  * Copyright (c) 2003, 2010, 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  */
  24 
  25 #ifndef SHARE_VM_RUNTIME_ORDERACCESS_HPP
  26 #define SHARE_VM_RUNTIME_ORDERACCESS_HPP
  27 
  28 #include "memory/allocation.hpp"
  29 
  30 //                Memory Access Ordering Model
  31 //
  32 // This interface is based on the JSR-133 Cookbook for Compiler Writers.
  33 //
  34 // In the following, the terms 'previous', 'subsequent', 'before',
  35 // 'after', 'preceding' and 'succeeding' refer to program order.  The
  36 // terms 'down' and 'below' refer to forward load or store motion
  37 // relative to program order, while 'up' and 'above' refer to backward
  38 // motion.
  39 //
  40 //
  41 // We define four primitive memory barrier operations.
  42 //
  43 // LoadLoad:   Load1(s); LoadLoad; Load2
  44 //
  45 // Ensures that Load1 completes (obtains the value it loads from memory)
  46 // before Load2 and any subsequent load operations.  Loads before Load1
  47 // may *not* float below Load2 and any subsequent load operations.
  48 //
  49 // StoreStore: Store1(s); StoreStore; Store2
  50 //
  51 // Ensures that Store1 completes (the effect on memory of Store1 is made
  52 // visible to other processors) before Store2 and any subsequent store
  53 // operations.  Stores before Store1 may *not* float below Store2 and any
  54 // subsequent store operations.
  55 //
  56 // LoadStore:  Load1(s); LoadStore; Store2
  57 //
  58 // Ensures that Load1 completes before Store2 and any subsequent store
  59 // operations.  Loads before Load1 may *not* float below Store2 and any
  60 // subsequent store operations.


  87 //
  88 // It is guaranteed that if T2: load(X) synchronizes with (observes the
  89 // value written by) T1: store(X), then the memory accesses before the T1:
  90 // ]release happen before the memory accesses after the T2: acquire[.
  91 //
  92 // Total Store Order (TSO) machines can be seen as machines issuing a
  93 // release store for each store and a load acquire for each load. Therefore
  94 // there is an inherent resemblence between TSO and acquire/release
  95 // semantics. TSO can be seen as an abstract machine where loads are
  96 // executed immediately when encountered (hence loadload reordering not
  97 // happening) but enqueues stores in a FIFO queue
  98 // for asynchronous serialization (neither storestore or loadstore
  99 // reordering happening). The only reordering happening is storeload due to
 100 // the queue asynchronously serializing stores (yet in order).
 101 //
 102 // Acquire/release semantics essentially exploits this asynchronicity: when
 103 // the load(X) acquire[ observes the store of ]release store(X), the
 104 // accesses before the release must have happened before the accesses after
 105 // acquire.
 106 //
 107 // The API offers both stand-alone acquire() and release() as well as joined
 108 // load_acquire() and release_store(). It is guaranteed that these are
 109 // semantically equivalent w.r.t. the defined model. However, since
 110 // stand-alone acquire()/release() does not know which previous
 111 // load/subsequent store is considered the synchronizing load/store, they
 112 // may be more conservative in implementations. We advice using the joined
 113 // variants whenever possible.
 114 //
 115 // Finally, we define a "fence" operation, as a bidirectional barrier.
 116 // It guarantees that any memory access preceding the fence is not
 117 // reordered w.r.t. any memory accesses subsequent to the fence in program
 118 // order. This may be used to prevent sequences of loads from floating up
 119 // above sequences of stores.
 120 //
 121 // The following table shows the implementations on some architectures:
 122 //
 123 //                       Constraint     x86          sparc              ppc
 124 // ---------------------------------------------------------------------------
 125 // fence                 LoadStore  |   lock         membar #StoreLoad  sync
 126 //                       StoreStore |   addl 0,(sp)
 127 //                       LoadLoad   |
 128 //                       StoreLoad
 129 //
 130 // release               LoadStore  |                                   lwsync
 131 //                       StoreStore
 132 //
 133 // acquire               LoadLoad   |                                   lwsync
 134 //                       LoadStore
 135 //
 136 // release_store                        <store>      <store>            lwsync
 137 //                                                                      <store>
 138 //
 139 // release_store_fence                  xchg         <store>            lwsync
 140 //                                                   membar #StoreLoad  <store>
 141 //                                                                      sync
 142 //
 143 //
 144 // load_acquire                         <load>       <load>             <load>
 145 //                                                                      lwsync
 146 //
 147 // Ordering a load relative to preceding stores requires a StoreLoad,
 148 // which implies a membar #StoreLoad between the store and load under
 149 // sparc-TSO. On x86, we use explicitly locked add.
 150 //
 151 // Conventional usage is to issue a load_acquire for ordered loads.  Use
 152 // release_store for ordered stores when you care only that prior stores
 153 // are visible before the release_store, but don't care exactly when the
 154 // store associated with the release_store becomes visible.  Use
 155 // release_store_fence to update values like the thread state, where we
 156 // don't want the current thread to continue until all our prior memory
 157 // accesses (including the new thread state) are visible to other threads.
 158 // This is equivalent to the volatile semantics of the Java Memory Model.
 159 //











 160 //
 161 //                os::is_MP Considered Redundant
 162 //
 163 // Callers of this interface do not need to test os::is_MP() before
 164 // issuing an operation. The test is taken care of by the implementation
 165 // of the interface (depending on the vm version and platform, the test
 166 // may or may not be actually done by the implementation).
 167 //
 168 //
 169 //                A Note on Memory Ordering and Cache Coherency
 170 //
 171 // Cache coherency and memory ordering are orthogonal concepts, though they
 172 // interact.  E.g., all existing itanium machines are cache-coherent, but
 173 // the hardware can freely reorder loads wrt other loads unless it sees a
 174 // load-acquire instruction.  All existing sparc machines are cache-coherent
 175 // and, unlike itanium, TSO guarantees that the hardware orders loads wrt
 176 // loads and stores, and stores wrt to each other.
 177 //
 178 // Consider the implementation of loadload.  *If* your platform *isn't*
 179 // cache-coherent, then loadload must not only prevent hardware load


   1 /*
   2  * Copyright (c) 2003, 2015, 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  */
  24 
  25 #ifndef SHARE_VM_RUNTIME_ORDERACCESS_HPP
  26 #define SHARE_VM_RUNTIME_ORDERACCESS_HPP
  27 
  28 #include "memory/allocation.hpp"
  29 
  30 //                Memory Access Ordering Model
  31 //
  32 // This interface is based on the JSR-133 Cookbook for Compiler Writers.
  33 //
  34 // In the following, the terms 'previous', 'subsequent', 'before',
  35 // 'after', 'preceding' and 'succeeding' refer to program order.  The
  36 // terms 'down' and 'below' refer to forward load or store motion
  37 // relative to program order, while 'up' and 'above' refer to backward
  38 // motion.
  39 //

  40 // We define four primitive memory barrier operations.
  41 //
  42 // LoadLoad:   Load1(s); LoadLoad; Load2
  43 //
  44 // Ensures that Load1 completes (obtains the value it loads from memory)
  45 // before Load2 and any subsequent load operations.  Loads before Load1
  46 // may *not* float below Load2 and any subsequent load operations.
  47 //
  48 // StoreStore: Store1(s); StoreStore; Store2
  49 //
  50 // Ensures that Store1 completes (the effect on memory of Store1 is made
  51 // visible to other processors) before Store2 and any subsequent store
  52 // operations.  Stores before Store1 may *not* float below Store2 and any
  53 // subsequent store operations.
  54 //
  55 // LoadStore:  Load1(s); LoadStore; Store2
  56 //
  57 // Ensures that Load1 completes before Store2 and any subsequent store
  58 // operations.  Loads before Load1 may *not* float below Store2 and any
  59 // subsequent store operations.


  86 //
  87 // It is guaranteed that if T2: load(X) synchronizes with (observes the
  88 // value written by) T1: store(X), then the memory accesses before the T1:
  89 // ]release happen before the memory accesses after the T2: acquire[.
  90 //
  91 // Total Store Order (TSO) machines can be seen as machines issuing a
  92 // release store for each store and a load acquire for each load. Therefore
  93 // there is an inherent resemblence between TSO and acquire/release
  94 // semantics. TSO can be seen as an abstract machine where loads are
  95 // executed immediately when encountered (hence loadload reordering not
  96 // happening) but enqueues stores in a FIFO queue
  97 // for asynchronous serialization (neither storestore or loadstore
  98 // reordering happening). The only reordering happening is storeload due to
  99 // the queue asynchronously serializing stores (yet in order).
 100 //
 101 // Acquire/release semantics essentially exploits this asynchronicity: when
 102 // the load(X) acquire[ observes the store of ]release store(X), the
 103 // accesses before the release must have happened before the accesses after
 104 // acquire.
 105 //
 106 // The API offers both stand-alone acquire() and release() as well as bound
 107 // load_acquire() and release_store(). It is guaranteed that these are
 108 // semantically equivalent w.r.t. the defined model. However, since
 109 // stand-alone acquire()/release() does not know which previous
 110 // load/subsequent store is considered the synchronizing load/store, they
 111 // may be more conservative in implementations. We advise using the bound
 112 // variants whenever possible.
 113 //
 114 // Finally, we define a "fence" operation, as a bidirectional barrier.
 115 // It guarantees that any memory access preceding the fence is not
 116 // reordered w.r.t. any memory accesses subsequent to the fence in program
 117 // order. This may be used to prevent sequences of loads from floating up
 118 // above sequences of stores.
 119 //
 120 // The following table shows the implementations on some architectures:
 121 //
 122 //                       Constraint     x86          sparc TSO          ppc
 123 // ---------------------------------------------------------------------------
 124 // fence                 LoadStore  |   lock         membar #StoreLoad  sync
 125 //                       StoreStore |   addl 0,(sp)
 126 //                       LoadLoad   |
 127 //                       StoreLoad
 128 //
 129 // release               LoadStore  |                                   lwsync
 130 //                       StoreStore
 131 //
 132 // acquire               LoadLoad   |                                   lwsync
 133 //                       LoadStore
 134 //
 135 // release_store                        <store>      <store>            lwsync
 136 //                                                                      <store>
 137 //
 138 // release_store_fence                  xchg         <store>            lwsync
 139 //                                                   membar #StoreLoad  <store>
 140 //                                                                      sync
 141 //
 142 //
 143 // load_acquire                         <load>       <load>             <load>
 144 //                                                                      lwsync
 145 //
 146 // Ordering a load relative to preceding stores requires a StoreLoad,
 147 // which implies a membar #StoreLoad between the store and load under
 148 // sparc-TSO. On x86, we use explicitly locked add.
 149 //
 150 // Conventional usage is to issue a load_acquire for ordered loads.  Use
 151 // release_store for ordered stores when you care only that prior stores
 152 // are visible before the release_store, but don't care exactly when the
 153 // store associated with the release_store becomes visible.  Use
 154 // release_store_fence to update values like the thread state, where we
 155 // don't want the current thread to continue until all our prior memory
 156 // accesses (including the new thread state) are visible to other threads.
 157 // This is equivalent to the volatile semantics of the Java Memory Model.
 158 //
 159 //                    C++ Volatile Semantics
 160 //
 161 // C++ volatile semantics prevent compiler re-ordering between
 162 // volatile memory accesses. However, reordering between non-volatile
 163 // and volatile memory accesses is in general undefined. For compiler
 164 // reordering constraints taking non-volatile memory accesses into
 165 // consideration, a compiler barrier has to be used instead.  Some
 166 // compiler implementations may choose to enforce additional
 167 // constraints beyond those required by the language. Note also that
 168 // both volatile semantics and compiler barrier do not prevent
 169 // hardware reordering.
 170 //
 171 //                os::is_MP Considered Redundant
 172 //
 173 // Callers of this interface do not need to test os::is_MP() before
 174 // issuing an operation. The test is taken care of by the implementation
 175 // of the interface (depending on the vm version and platform, the test
 176 // may or may not be actually done by the implementation).
 177 //
 178 //
 179 //                A Note on Memory Ordering and Cache Coherency
 180 //
 181 // Cache coherency and memory ordering are orthogonal concepts, though they
 182 // interact.  E.g., all existing itanium machines are cache-coherent, but
 183 // the hardware can freely reorder loads wrt other loads unless it sees a
 184 // load-acquire instruction.  All existing sparc machines are cache-coherent
 185 // and, unlike itanium, TSO guarantees that the hardware orders loads wrt
 186 // loads and stores, and stores wrt to each other.
 187 //
 188 // Consider the implementation of loadload.  *If* your platform *isn't*
 189 // cache-coherent, then loadload must not only prevent hardware load


< prev index next >