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 #include "precompiled.hpp"
26 #include "accessBackend.inline.hpp"
27 #include "gc/shared/collectedHeap.hpp"
28 #include "oops/oop.inline.hpp"
29 #include "runtime/mutexLocker.hpp"
30 #include "runtime/vm_version.hpp"
31 #include "utilities/copy.hpp"
32
33 namespace AccessInternal {
34 // VM_Version::supports_cx8() is a surrogate for 'supports atomic long memory ops'.
35 //
36 // On platforms which do not support atomic compare-and-swap of jlong (8 byte)
37 // values we have to use a lock-based scheme to enforce atomicity. This has to be
38 // applied to all Unsafe operations that set the value of a jlong field. Even so
39 // the compareAndSwapLong operation will not be atomic with respect to direct stores
40 // to the field from Java code. It is important therefore that any Java code that
41 // utilizes these Unsafe jlong operations does not perform direct stores. To permit
42 // direct loads of the field from Java code we must also use Atomic::store within the
43 // locked regions. And for good measure, in case there are direct stores, we also
44 // employ Atomic::load within those regions. Note that the field in question must be
45 // volatile and so must have atomic load/store accesses applied at the Java level.
46 //
47 // The locking scheme could utilize a range of strategies for controlling the locking
48 // granularity: from a lock per-field through to a single global lock. The latter is
|
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 #include "precompiled.hpp"
26 #include "accessBackend.inline.hpp"
27 #include "gc/shared/collectedHeap.hpp"
28 #include "oops/oop.inline.hpp"
29 #include "oops/valueKlass.hpp"
30 #include "runtime/mutexLocker.hpp"
31 #include "runtime/vm_version.hpp"
32 #include "utilities/copy.hpp"
33
34 namespace AccessInternal {
35 // VM_Version::supports_cx8() is a surrogate for 'supports atomic long memory ops'.
36 //
37 // On platforms which do not support atomic compare-and-swap of jlong (8 byte)
38 // values we have to use a lock-based scheme to enforce atomicity. This has to be
39 // applied to all Unsafe operations that set the value of a jlong field. Even so
40 // the compareAndSwapLong operation will not be atomic with respect to direct stores
41 // to the field from Java code. It is important therefore that any Java code that
42 // utilizes these Unsafe jlong operations does not perform direct stores. To permit
43 // direct loads of the field from Java code we must also use Atomic::store within the
44 // locked regions. And for good measure, in case there are direct stores, we also
45 // employ Atomic::load within those regions. Note that the field in question must be
46 // volatile and so must have atomic load/store accesses applied at the Java level.
47 //
48 // The locking scheme could utilize a range of strategies for controlling the locking
49 // granularity: from a lock per-field through to a single global lock. The latter is
|