49658
|
1 |
/*
|
|
2 |
* Copyright (c) 2018, 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_OOPS_ACCESSDECORATORS_HPP
|
|
26 |
#define SHARE_OOPS_ACCESSDECORATORS_HPP
|
|
27 |
|
|
28 |
// A decorator is an attribute or property that affects the way a memory access is performed in some way.
|
|
29 |
// There are different groups of decorators. Some have to do with memory ordering, others to do with,
|
|
30 |
// e.g. strength of references, strength of GC barriers, or whether compression should be applied or not.
|
|
31 |
// Some decorators are set at buildtime, such as whether primitives require GC barriers or not, others
|
|
32 |
// at callsites such as whether an access is in the heap or not, and others are resolved at runtime
|
|
33 |
// such as GC-specific barriers and encoding/decoding compressed oops.
|
|
34 |
typedef uint64_t DecoratorSet;
|
|
35 |
|
|
36 |
// The HasDecorator trait can help at compile-time determining whether a decorator set
|
|
37 |
// has an intersection with a certain other decorator set
|
|
38 |
template <DecoratorSet decorators, DecoratorSet decorator>
|
|
39 |
struct HasDecorator: public IntegralConstant<bool, (decorators & decorator) != 0> {};
|
|
40 |
|
|
41 |
// == Internal Decorators - do not use ==
|
|
42 |
// * INTERNAL_EMPTY: This is the name for the empty decorator set (in absence of other decorators).
|
|
43 |
// * INTERNAL_CONVERT_COMPRESSED_OOPS: This is an oop access that will require converting an oop
|
|
44 |
// to a narrowOop or vice versa, if UseCompressedOops is known to be set.
|
|
45 |
// * INTERNAL_VALUE_IS_OOP: Remember that the involved access is on oop rather than primitive.
|
|
46 |
const DecoratorSet INTERNAL_EMPTY = UCONST64(0);
|
|
47 |
const DecoratorSet INTERNAL_CONVERT_COMPRESSED_OOP = UCONST64(1) << 1;
|
|
48 |
const DecoratorSet INTERNAL_VALUE_IS_OOP = UCONST64(1) << 2;
|
|
49 |
|
|
50 |
// == Internal build-time Decorators ==
|
|
51 |
// * INTERNAL_BT_BARRIER_ON_PRIMITIVES: This is set in the barrierSetConfig.hpp file.
|
|
52 |
// * INTERNAL_BT_TO_SPACE_INVARIANT: This is set in the barrierSetConfig.hpp file iff
|
|
53 |
// no GC is bundled in the build that is to-space invariant.
|
|
54 |
const DecoratorSet INTERNAL_BT_BARRIER_ON_PRIMITIVES = UCONST64(1) << 3;
|
|
55 |
const DecoratorSet INTERNAL_BT_TO_SPACE_INVARIANT = UCONST64(1) << 4;
|
|
56 |
|
|
57 |
// == Internal run-time Decorators ==
|
|
58 |
// * INTERNAL_RT_USE_COMPRESSED_OOPS: This decorator will be set in runtime resolved
|
|
59 |
// access backends iff UseCompressedOops is true.
|
|
60 |
const DecoratorSet INTERNAL_RT_USE_COMPRESSED_OOPS = UCONST64(1) << 5;
|
|
61 |
|
|
62 |
const DecoratorSet INTERNAL_DECORATOR_MASK = INTERNAL_CONVERT_COMPRESSED_OOP | INTERNAL_VALUE_IS_OOP |
|
|
63 |
INTERNAL_BT_BARRIER_ON_PRIMITIVES | INTERNAL_RT_USE_COMPRESSED_OOPS;
|
|
64 |
|
|
65 |
// == Memory Ordering Decorators ==
|
|
66 |
// The memory ordering decorators can be described in the following way:
|
|
67 |
// === Decorator Rules ===
|
|
68 |
// The different types of memory ordering guarantees have a strict order of strength.
|
|
69 |
// Explicitly specifying the stronger ordering implies that the guarantees of the weaker
|
|
70 |
// property holds too. The names come from the C++11 atomic operations, and typically
|
|
71 |
// have a JMM equivalent property.
|
|
72 |
// The equivalence may be viewed like this:
|
|
73 |
// MO_UNORDERED is equivalent to JMM plain.
|
|
74 |
// MO_VOLATILE has no equivalence in JMM, because it's a C++ thing.
|
|
75 |
// MO_RELAXED is equivalent to JMM opaque.
|
|
76 |
// MO_ACQUIRE is equivalent to JMM acquire.
|
|
77 |
// MO_RELEASE is equivalent to JMM release.
|
|
78 |
// MO_SEQ_CST is equivalent to JMM volatile.
|
|
79 |
//
|
|
80 |
// === Stores ===
|
|
81 |
// * MO_UNORDERED (Default): No guarantees.
|
|
82 |
// - The compiler and hardware are free to reorder aggressively. And they will.
|
|
83 |
// * MO_VOLATILE: Volatile stores (in the C++ sense).
|
|
84 |
// - The stores are not reordered by the compiler (but possibly the HW) w.r.t. other
|
|
85 |
// volatile accesses in program order (but possibly non-volatile accesses).
|
|
86 |
// * MO_RELAXED: Relaxed atomic stores.
|
|
87 |
// - The stores are atomic.
|
|
88 |
// - Guarantees from volatile stores hold.
|
|
89 |
// * MO_RELEASE: Releasing stores.
|
|
90 |
// - The releasing store will make its preceding memory accesses observable to memory accesses
|
|
91 |
// subsequent to an acquiring load observing this releasing store.
|
|
92 |
// - Guarantees from relaxed stores hold.
|
|
93 |
// * MO_SEQ_CST: Sequentially consistent stores.
|
|
94 |
// - The stores are observed in the same order by MO_SEQ_CST loads on other processors
|
|
95 |
// - Preceding loads and stores in program order are not reordered with subsequent loads and stores in program order.
|
|
96 |
// - Guarantees from releasing stores hold.
|
|
97 |
// === Loads ===
|
|
98 |
// * MO_UNORDERED (Default): No guarantees
|
|
99 |
// - The compiler and hardware are free to reorder aggressively. And they will.
|
|
100 |
// * MO_VOLATILE: Volatile loads (in the C++ sense).
|
|
101 |
// - The loads are not reordered by the compiler (but possibly the HW) w.r.t. other
|
|
102 |
// volatile accesses in program order (but possibly non-volatile accesses).
|
|
103 |
// * MO_RELAXED: Relaxed atomic loads.
|
|
104 |
// - The loads are atomic.
|
|
105 |
// - Guarantees from volatile loads hold.
|
|
106 |
// * MO_ACQUIRE: Acquiring loads.
|
|
107 |
// - An acquiring load will make subsequent memory accesses observe the memory accesses
|
|
108 |
// preceding the releasing store that the acquiring load observed.
|
|
109 |
// - Guarantees from relaxed loads hold.
|
|
110 |
// * MO_SEQ_CST: Sequentially consistent loads.
|
|
111 |
// - These loads observe MO_SEQ_CST stores in the same order on other processors
|
|
112 |
// - Preceding loads and stores in program order are not reordered with subsequent loads and stores in program order.
|
|
113 |
// - Guarantees from acquiring loads hold.
|
|
114 |
// === Atomic Cmpxchg ===
|
|
115 |
// * MO_RELAXED: Atomic but relaxed cmpxchg.
|
|
116 |
// - Guarantees from MO_RELAXED loads and MO_RELAXED stores hold unconditionally.
|
|
117 |
// * MO_SEQ_CST: Sequentially consistent cmpxchg.
|
|
118 |
// - Guarantees from MO_SEQ_CST loads and MO_SEQ_CST stores hold unconditionally.
|
|
119 |
// === Atomic Xchg ===
|
|
120 |
// * MO_RELAXED: Atomic but relaxed atomic xchg.
|
|
121 |
// - Guarantees from MO_RELAXED loads and MO_RELAXED stores hold.
|
|
122 |
// * MO_SEQ_CST: Sequentially consistent xchg.
|
|
123 |
// - Guarantees from MO_SEQ_CST loads and MO_SEQ_CST stores hold.
|
|
124 |
const DecoratorSet MO_UNORDERED = UCONST64(1) << 6;
|
|
125 |
const DecoratorSet MO_VOLATILE = UCONST64(1) << 7;
|
|
126 |
const DecoratorSet MO_RELAXED = UCONST64(1) << 8;
|
|
127 |
const DecoratorSet MO_ACQUIRE = UCONST64(1) << 9;
|
|
128 |
const DecoratorSet MO_RELEASE = UCONST64(1) << 10;
|
|
129 |
const DecoratorSet MO_SEQ_CST = UCONST64(1) << 11;
|
|
130 |
const DecoratorSet MO_DECORATOR_MASK = MO_UNORDERED | MO_VOLATILE | MO_RELAXED |
|
|
131 |
MO_ACQUIRE | MO_RELEASE | MO_SEQ_CST;
|
|
132 |
|
|
133 |
// === Barrier Strength Decorators ===
|
|
134 |
// * AS_RAW: The access will translate into a raw memory access, hence ignoring all semantic concerns
|
|
135 |
// except memory ordering and compressed oops. This will bypass runtime function pointer dispatching
|
|
136 |
// in the pipeline and hardwire to raw accesses without going trough the GC access barriers.
|
|
137 |
// - Accesses on oop* translate to raw memory accesses without runtime checks
|
|
138 |
// - Accesses on narrowOop* translate to encoded/decoded memory accesses without runtime checks
|
|
139 |
// - Accesses on HeapWord* translate to a runtime check choosing one of the above
|
|
140 |
// - Accesses on other types translate to raw memory accesses without runtime checks
|
|
141 |
// * AS_DEST_NOT_INITIALIZED: This property can be important to e.g. SATB barriers by
|
|
142 |
// marking that the previous value is uninitialized nonsense rather than a real value.
|
|
143 |
// * AS_NO_KEEPALIVE: The barrier is used only on oop references and will not keep any involved objects
|
|
144 |
// alive, regardless of the type of reference being accessed. It will however perform the memory access
|
|
145 |
// in a consistent way w.r.t. e.g. concurrent compaction, so that the right field is being accessed,
|
|
146 |
// or maintain, e.g. intergenerational or interregional pointers if applicable. This should be used with
|
|
147 |
// extreme caution in isolated scopes.
|
|
148 |
// * AS_NORMAL: The accesses will be resolved to an accessor on the BarrierSet class, giving the
|
|
149 |
// responsibility of performing the access and what barriers to be performed to the GC. This is the default.
|
|
150 |
// Note that primitive accesses will only be resolved on the barrier set if the appropriate build-time
|
|
151 |
// decorator for enabling primitive barriers is enabled for the build.
|
|
152 |
const DecoratorSet AS_RAW = UCONST64(1) << 12;
|
|
153 |
const DecoratorSet AS_DEST_NOT_INITIALIZED = UCONST64(1) << 13;
|
|
154 |
const DecoratorSet AS_NO_KEEPALIVE = UCONST64(1) << 14;
|
|
155 |
const DecoratorSet AS_NORMAL = UCONST64(1) << 15;
|
|
156 |
const DecoratorSet AS_DECORATOR_MASK = AS_RAW | AS_DEST_NOT_INITIALIZED |
|
|
157 |
AS_NO_KEEPALIVE | AS_NORMAL;
|
|
158 |
|
|
159 |
// === Reference Strength Decorators ===
|
|
160 |
// These decorators only apply to accesses on oop-like types (oop/narrowOop).
|
|
161 |
// * ON_STRONG_OOP_REF: Memory access is performed on a strongly reachable reference.
|
|
162 |
// * ON_WEAK_OOP_REF: The memory access is performed on a weakly reachable reference.
|
|
163 |
// * ON_PHANTOM_OOP_REF: The memory access is performed on a phantomly reachable reference.
|
|
164 |
// This is the same ring of strength as jweak and weak oops in the VM.
|
|
165 |
// * ON_UNKNOWN_OOP_REF: The memory access is performed on a reference of unknown strength.
|
|
166 |
// This could for example come from the unsafe API.
|
|
167 |
// * Default (no explicit reference strength specified): ON_STRONG_OOP_REF
|
|
168 |
const DecoratorSet ON_STRONG_OOP_REF = UCONST64(1) << 16;
|
|
169 |
const DecoratorSet ON_WEAK_OOP_REF = UCONST64(1) << 17;
|
|
170 |
const DecoratorSet ON_PHANTOM_OOP_REF = UCONST64(1) << 18;
|
|
171 |
const DecoratorSet ON_UNKNOWN_OOP_REF = UCONST64(1) << 19;
|
|
172 |
const DecoratorSet ON_DECORATOR_MASK = ON_STRONG_OOP_REF | ON_WEAK_OOP_REF |
|
|
173 |
ON_PHANTOM_OOP_REF | ON_UNKNOWN_OOP_REF;
|
|
174 |
|
|
175 |
// === Access Location ===
|
|
176 |
// Accesses can take place in, e.g. the heap, old or young generation and different native roots.
|
|
177 |
// The location is important to the GC as it may imply different actions. The following decorators are used:
|
|
178 |
// * IN_HEAP: The access is performed in the heap. Many barriers such as card marking will
|
|
179 |
// be omitted if this decorator is not set.
|
|
180 |
// * IN_HEAP_ARRAY: The access is performed on a heap allocated array. This is sometimes a special case
|
|
181 |
// for some GCs, and implies that it is an IN_HEAP.
|
|
182 |
// * IN_ROOT: The access is performed in an off-heap data structure pointing into the Java heap.
|
|
183 |
// * IN_CONCURRENT_ROOT: The access is performed in an off-heap data structure pointing into the Java heap,
|
|
184 |
// but is notably not scanned during safepoints. This is sometimes a special case for some GCs and
|
|
185 |
// implies that it is also an IN_ROOT.
|
|
186 |
const DecoratorSet IN_HEAP = UCONST64(1) << 20;
|
|
187 |
const DecoratorSet IN_HEAP_ARRAY = UCONST64(1) << 21;
|
|
188 |
const DecoratorSet IN_ROOT = UCONST64(1) << 22;
|
|
189 |
const DecoratorSet IN_CONCURRENT_ROOT = UCONST64(1) << 23;
|
|
190 |
const DecoratorSet IN_ARCHIVE_ROOT = UCONST64(1) << 24;
|
|
191 |
const DecoratorSet IN_DECORATOR_MASK = IN_HEAP | IN_HEAP_ARRAY |
|
|
192 |
IN_ROOT | IN_CONCURRENT_ROOT |
|
|
193 |
IN_ARCHIVE_ROOT;
|
|
194 |
|
|
195 |
// == Value Decorators ==
|
|
196 |
// * OOP_NOT_NULL: This property can make certain barriers faster such as compressing oops.
|
|
197 |
const DecoratorSet OOP_NOT_NULL = UCONST64(1) << 25;
|
|
198 |
const DecoratorSet OOP_DECORATOR_MASK = OOP_NOT_NULL;
|
|
199 |
|
|
200 |
// == Arraycopy Decorators ==
|
|
201 |
// * ARRAYCOPY_CHECKCAST: This property means that the class of the objects in source
|
|
202 |
// are not guaranteed to be subclasses of the class of the destination array. This requires
|
|
203 |
// a check-cast barrier during the copying operation. If this is not set, it is assumed
|
|
204 |
// that the array is covariant: (the source array type is-a destination array type)
|
|
205 |
// * ARRAYCOPY_DISJOINT: This property means that it is known that the two array ranges
|
|
206 |
// are disjoint.
|
|
207 |
// * ARRAYCOPY_ARRAYOF: The copy is in the arrayof form.
|
|
208 |
// * ARRAYCOPY_ATOMIC: The accesses have to be atomic over the size of its elements.
|
|
209 |
// * ARRAYCOPY_ALIGNED: The accesses have to be aligned on a HeapWord.
|
|
210 |
const DecoratorSet ARRAYCOPY_CHECKCAST = UCONST64(1) << 26;
|
|
211 |
const DecoratorSet ARRAYCOPY_DISJOINT = UCONST64(1) << 27;
|
|
212 |
const DecoratorSet ARRAYCOPY_ARRAYOF = UCONST64(1) << 28;
|
|
213 |
const DecoratorSet ARRAYCOPY_ATOMIC = UCONST64(1) << 29;
|
|
214 |
const DecoratorSet ARRAYCOPY_ALIGNED = UCONST64(1) << 30;
|
|
215 |
const DecoratorSet ARRAYCOPY_DECORATOR_MASK = ARRAYCOPY_CHECKCAST | ARRAYCOPY_DISJOINT |
|
|
216 |
ARRAYCOPY_DISJOINT | ARRAYCOPY_ARRAYOF |
|
|
217 |
ARRAYCOPY_ATOMIC | ARRAYCOPY_ALIGNED;
|
|
218 |
|
|
219 |
#endif // SHARE_OOPS_ACCESSDECORATORS_HPP
|