A VarHandle is a dynamically typed reference to a variable, or to a parametrically-defined family of variables, including static fields, non-static fields, array elements, or components of an off-heap data structure. Access to such variables is supported under various
access modes , including plain read/write access, volatile read/write access, and compare-and-swap.
VarHandles are immutable and have no visible state. VarHandles cannot be subclassed by the user.
A VarHandle has:
- a
variable type
, referred to as T
, which is the type of variable(s) referenced by this VarHandle;
- a list of
coordinate types
, referred to as CT
, where the types (primitive and reference) are represented by Class
objects). A list of arguments corresponding to instances of the coordinate types uniquely locates a variable referenced by this VarHandle; and
- a shape, that combines the variable type and coordinate types, and is declared with the notation
(CT : T)
. An empty list of coordinate types is declared as (empty)
.
Factory methods that produce or lookup
VarHandle instances document the supported variable type, coordinate types, and shape. For example, a VarHandle referencing a non-static field will declare a shape of (R : T)
, where R
is the receiver type and T
is the field type, and where the VarHandle and an instance of the receiver type can be utilized to access the field variable. A VarHandle referencing array elements will declare a shape of (T[], int : T)
, where T[]
is the array type and T
its component type, and where the VarHandle, an instance of the array type, and an int
index can be utilized to access an array element variable.
Each access mode is associated with a signature polymorphic method of the same name, where the VarHandle shape and access mode uniquely determine the canonical access mode type
, which in turn determines the matching constraints on a valid symbolic type descriptor at the call site of an access mode's method invocation. As such, VarHandles are dynamically and strongly typed. Their arity, argument types, and return type of an access mode method invocation are not statically checked. If they, and associated values, do not match the arity and types of the access mode's type, an exception will be thrown. The parameter types of an access mode method type will consist of those that are the VarHandles's coordinate types (in order), followed by access mode parameter types specific to the access mode.
An access mode's method documents the form of its method signature, which is derived from the access mode parameter types. The form is declared with the notation (CT, P1 p1, P2 p2, ..., PN pn)R
, where CT
is the coordinate types (as documented by a VarHandle factory method), P1
, P2
and PN
are the first, second and the n'th access mode parameters named p1
, p2
and pn
respectively, and R
is the return type. For example, for the generic shape of (CT : T)
the compareAndSet(java.lang.Object...)
access mode method documents that its method signature is of the form (CT, T expectedValue, T newValue)boolean
, where the parameter types named extendedValue
and newValue
are the access mode parameter types. If the VarHandle accesses array elements with a shape of say (T[], int : T)
then the access mode method type is (T[], int, T, T)boolean
.
Access modes are grouped into the following categories:
- read access modes that get the value of a variable under specified memory ordering effects. The set of corresponding access mode methods belonging to this group consists of the methods
get
, getVolatile
, getAcquire
, getOpaque
.
- write access modes that set the value of a variable under specified memory ordering effects. The set of corresponding access mode methods belonging to this group consists of the methods
set
, setVolatile
, setRelease
, setOpaque
.
- atomic update access modes that, for example, atomically compare and set the value of a variable under specified memory ordering effects. The set of corresponding access mode methods belonging to this group consists of the methods
compareAndSet
, weakCompareAndSetPlain
, weakCompareAndSet
, weakCompareAndSetAcquire
, weakCompareAndSetRelease
, compareAndExchangeAcquire
, compareAndExchange
, compareAndExchangeRelease
, getAndSet
, getAndSetAcquire
, getAndSetRelease
.
- numeric atomic update access modes that, for example, atomically get and set with addition the value of a variable under specified memory ordering effects. The set of corresponding access mode methods belonging to this group consists of the methods
getAndAdd
, getAndAddAcquire
, getAndAddRelease
,
- bitwise atomic update access modes that, for example, atomically get and bitwise OR the value of a variable under specified memory ordering effects. The set of corresponding access mode methods belonging to this group consists of the methods
getAndBitwiseOr
, getAndBitwiseOrAcquire
, getAndBitwiseOrRelease
, getAndBitwiseAnd
, getAndBitwiseAndAcquire
, getAndBitwiseAndRelease
, getAndBitwiseXor
, getAndBitwiseXorAcquire
, getAndBitwiseXorRelease
.
Factory methods that produce or lookup
VarHandle instances document the set of access modes that are supported, which may also include documenting restrictions based on the variable type and whether a variable is read-only. If an access mode is not supported then the corresponding signature-polymorphic method will on invocation throw an UnsupportedOperationException
. Factory methods should document any additional undeclared exceptions that may be thrown by access mode methods. The get
access mode is supported for all VarHandle instances and the corresponding method never throws UnsupportedOperationException
. If a VarHandle references a read-only variable (for example a final
field) then write, atomic update, numeric atomic update, and bitwise atomic update access modes are not supported and corresponding methods throw UnsupportedOperationException
. Read/write access modes (if supported), with the exception of get
and set
, provide atomic access for reference types and all primitive types. Unless stated otherwise in the documentation of a factory method, the access modes get
and set
(if supported) provide atomic access for reference types and all primitives types, with the exception of long
and double
on 32-bit platforms.
Access modes will override any memory ordering effects specified at the declaration site of a variable. For example, a VarHandle accessing a a field using the get
access mode will access the field as specified by its access mode even if that field is declared volatile
. When mixed access is performed extreme care should be taken since the Java Memory Model may permit surprising results.
In addition to supporting access to variables under various access modes, a set of static methods, referred to as memory fence methods, is also provided for fine-grained control of memory ordering. The Java Language Specification permits other threads to observe operations as if they were executed in orders different than are apparent in program source code, subject to constraints arising, for example, from the use of locks, volatile
fields or VarHandles. The static methods, fullFence
, acquireFence
, releaseFence
, loadLoadFence
and storeStoreFence
, can also be used to impose constraints. Their specifications, as is the case for certain access modes, are phrased in terms of the lack of "reorderings" -- observable ordering effects that might otherwise occur if the fence was not present. More precise phrasing of the specification of access mode methods and memory fence methods may accompany future updates of the Java Language Specification.
Compilation of an access mode's method
A Java method call expression naming an access mode method can invoke a VarHandle from Java source code. From the viewpoint of source code, these methods can take any arguments and their polymorphic result (if expressed) can be cast to any return type. Formally this is accomplished by giving the access mode methods variable arity
Object
arguments and
Object
return types (if the return type is polymorphic), but they have an additional quality called
signature polymorphism which connects this freedom of invocation directly to the JVM execution stack.
As is usual with virtual methods, source-level calls to access mode methods compile to an invokevirtual
instruction. More unusually, the compiler must record the actual argument types, and may not perform method invocation conversions on the arguments. Instead, it must generate instructions to push them on the stack according to their own unconverted types. The VarHandle object itself will be pushed on the stack before the arguments. The compiler then generates an invokevirtual
instruction that invokes the access mode method with a symbolic type descriptor which describes the argument and return types.
To issue a complete symbolic type descriptor, the compiler must also determine the return type (if polymorphic). This is based on a cast on the method invocation expression, if there is one, or else Object
if the invocation is an expression, or else void
if the invocation is a statement. The cast may be to a primitive type (but not void
).
As a corner case, an uncasted null
argument is given a symbolic type descriptor of java.lang.Void
. The ambiguity with the type Void
is harmless, since there are no references of type Void
except the null reference.
The first time an
invokevirtual
instruction is executed it is linked by symbolically resolving the names in the instruction and verifying that the method call is statically legal. This also holds for calls to access mode methods. In this case, the symbolic type descriptor emitted by the compiler is checked for correct syntax, and names it contains are resolved. Thus, an
invokevirtual
instruction which invokes an access mode method will always link, as long as the symbolic type descriptor is syntactically well-formed and the types exist.
When the invokevirtual
is executed after linking, the receiving VarHandle's access mode type is first checked by the JVM to ensure that it matches the symbolic type descriptor. If the type match fails, it means that the access mode method which the caller is invoking is not present on the individual VarHandle being invoked.
Invocation of an access mode's signature-polymorphic method behaves as if an invocation of MethodHandle.invoke(java.lang.Object...)
, where the receiving method handle is bound to a VarHandle instance and the access mode. More specifically, the following:
VarHandle vh = ..
R r = (R) vh.{access-mode}(p1, p2, ..., pN);
behaves as if (modulo the access mode methods do not declare throwing of
Throwable
):
VarHandle vh = ..
MethodHandle mh = MethodHandles.varHandleExactInvoker(
VarHandle.AccessMode.{access-mode},
vh.accessModeType(VarHandle.AccessMode.{access-mode}));
mh = mh.bindTo(vh);
R r = (R) mh.invoke(p1, p2, ..., pN)
or, more concisely, behaves as if:
VarHandle vh = ..
MethodHandle mh = vh.toMethodHandle(VarHandle.AccessMode.{access-mode});
R r = (R) mh.invoke(p1, p2, ..., pN)
In terms of equivalent
invokevirtual
bytecode behaviour an access mode method invocation is equivalent to:
MethodHandle mh = MethodHandles.lookup().findVirtual(
VarHandle.class,
VarHandle.AccessMode.{access-mode}.methodName(),
MethodType.methodType(R, p1, p2, ..., pN));
R r = (R) mh.invokeExact(vh, p1, p2, ..., pN)
where the desired method type is the symbolic type descriptor and a
MethodHandle.invokeExact(java.lang.Object...)
is performed, since before invocation of the target, the handle will apply reference casts as necessary and box, unbox, or widen primitive values, as if by
asType
(see also
MethodHandles.varHandleInvoker(java.lang.invoke.VarHandle.AccessMode, java.lang.invoke.MethodType)
).
Invocation checking
In typical programs, VarHandle access mode type matching will usually succeed. But if a match fails, the JVM will throw a
WrongMethodTypeException
.
Thus, an access mode type mismatch which might show up as a linkage error in a statically typed program can show up as a dynamic WrongMethodTypeException
in a program which uses VarHandles.
Because access mode types contain "live" Class
objects, method type matching takes into account both type names and class loaders. Thus, even if a VarHandle VH
is created in one class loader L1
and used in another L2
, VarHandle access mode method calls are type-safe, because the caller's symbolic type descriptor, as resolved in L2
, is matched against the original callee method's symbolic type descriptor, as resolved in L1
. The resolution in L1
happens when VH
is created and its access mode types are assigned, while the resolution in L2
happens when the invokevirtual
instruction is linked.
Apart from type descriptor checks, a VarHandles's capability to access it's variables is unrestricted. If a VarHandle is formed on a non-public variable by a class that has access to that variable, the resulting VarHandle can be used in any place by any caller who receives a reference to it.
Unlike with the Core Reflection API, where access is checked every time a reflective method is invoked, VarHandle access checking is performed when the VarHandle is created . Thus, VarHandles to non-public variables, or to variables in non-public classes, should generally be kept secret. They should not be passed to untrusted code unless their use from the untrusted code would be harmless.
VarHandle creation
Java code can create a VarHandle that directly accesses any field that is accessible to that code. This is done via a reflective, capability-based API called
MethodHandles.Lookup
. For example, a VarHandle for a non-static field can be obtained from
Lookup.findVarHandle
. There is also a conversion method from Core Reflection API objects,
Lookup.unreflectVarHandle
.
Access to protected field members is restricted to receivers only of the accessing class, or one of its subclasses, and the accessing class must in turn be a subclass (or package sibling) of the protected member's defining class. If a VarHandle refers to a protected non-static field of a declaring class outside the current package, the receiver argument will be narrowed to the type of the accessing class.
Interoperation between VarHandles and the Core Reflection API
Using factory methods in the
Lookup
API, any field represented by a Core Reflection API object can be converted to a behaviorally equivalent VarHandle. For example, a reflective
Field
can be converted to a VarHandle using
Lookup.unreflectVarHandle
. The resulting VarHandles generally provide more direct and efficient access to the underlying fields.
As a special case, when the Core Reflection API is used to view the signature polymorphic access mode methods in this class, they appear as ordinary non-polymorphic methods. Their reflective appearance, as viewed by Class.getDeclaredMethod
, is unaffected by their special status in this API. For example, Method.getModifiers
will report exactly those modifier bits required for any similarly declared method, including in this case native
and varargs
bits.
As with any reflected method, these methods (when reflected) may be invoked directly via java.lang.reflect.Method.invoke
, via JNI, or indirectly via Lookup.unreflect
. However, such reflective calls do not result in access mode method invocations. Such a call, if passed the required argument (a single one, of type Object[]
), will ignore the argument and will throw an UnsupportedOperationException
.
Since invokevirtual
instructions can natively invoke VarHandle access mode methods under any symbolic type descriptor, this reflective view conflicts with the normal presentation of these methods via bytecodes. Thus, these native methods, when reflectively viewed by Class.getDeclaredMethod
, may be regarded as placeholders only.
In order to obtain an invoker method for a particular access mode type, use MethodHandles.varHandleExactInvoker(java.lang.invoke.VarHandle.AccessMode, java.lang.invoke.MethodType)
or MethodHandles.varHandleInvoker(java.lang.invoke.VarHandle.AccessMode, java.lang.invoke.MethodType)
. The Lookup.findVirtual
API is also able to return a method handle to call an access mode method for any specified access mode type and is equivalent in behaviour to MethodHandles.varHandleInvoker(java.lang.invoke.VarHandle.AccessMode, java.lang.invoke.MethodType)
.
Interoperation between VarHandles and Java generics
A VarHandle can be obtained for a variable, such as a a field, which is declared with Java generic types. As with the Core Reflection API, the VarHandle's variable type will be constructed from the erasure of the source-level type. When a VarHandle access mode method is invoked, the types of its arguments or the return value cast type may be generic types or type instances. If this occurs, the compiler will replace those types by their erasures when it constructs the symbolic type descriptor for the
invokevirtual
instruction.