Package org.jctools.util

Class UnsafeAccess

java.lang.Object

org.jctools.util.UnsafeAccess

public class UnsafeAccess
extends java.lang.Object

Why should we resort to using Unsafe?

1. To construct class fields which allow volatile/ordered/plain access: This requirement is covered by AtomicReferenceFieldUpdater and similar but their performance is arguably worse than the DIY approach (depending on JVM version) while Unsafe intrinsification is a far lesser challenge for JIT compilers.
2. To construct flavors of AtomicReferenceArray.
3. Other use cases exist but are not present in this library yet.

Field Summary

Fields

Modifier and Type	Field	Description
static boolean	SUPPORTS_GET_AND_ADD_LONG
static boolean	SUPPORTS_GET_AND_SET_REF
static sun.misc.Unsafe	UNSAFE

Constructor Summary

Constructors

Constructor	Description
UnsafeAccess()

Method Summary

Modifier and Type	Method	Description
static long	fieldOffset(java.lang.Class clz, java.lang.String fieldName)
private static sun.misc.Unsafe	getUnsafe()
private static boolean	hasGetAndAddLongSupport()
private static boolean	hasGetAndSetSupport()

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Field Detail

SUPPORTS_GET_AND_SET_REF

public static final boolean SUPPORTS_GET_AND_SET_REF

SUPPORTS_GET_AND_ADD_LONG

public static final boolean SUPPORTS_GET_AND_ADD_LONG

UNSAFE

public static final sun.misc.Unsafe UNSAFE

Constructor Detail

UnsafeAccess

public UnsafeAccess()

Method Detail

getUnsafe

private static sun.misc.Unsafe getUnsafe()

hasGetAndSetSupport

private static boolean hasGetAndSetSupport()

hasGetAndAddLongSupport

private static boolean hasGetAndAddLongSupport()

fieldOffset

public static long fieldOffset(java.lang.Class clz,
                               java.lang.String fieldName)
                        throws java.lang.RuntimeException

Throws:

java.lang.RuntimeException