[concurrency-interest] New field accessor APIs

Rémi Forax forax at univ-mlv.fr
Fri Nov 26 16:46:10 EST 2010

On 11/26/2010 08:34 PM, John Platts wrote:
> Here are reasons why new field accessor APIs are needed:
> - To improve portability, correctness, and thread safety of code using the improved field accessor APIs. Writes to reference fields through methods in sun.misc.Unsafe are not type safe. The sun.misc.Unsafe class is not part of the Java SE specification and is not guaranteed to be available in a Java SE implementation.
> - To allow volatile reads, volatile writes, lazy volatile writes, and atomic operations to be performed on non-volatile fields. These operations are often useful on non-volatile fields as they enable thread-safe initialization of non-volatile fields, while allowing subsequent accesses to be optimized. Supporting volatile writes of non-volatile fields also allows inversion of control and dependency control containers to ensure that non-volatile fields are properly initialized and written to in a thread-safe manner.

You can use invokedynamic and its bootstrap method mechanism to 
implement a lazy initialization.

> - To allow field updaters to be created through lookup classes (similar to the java.dyn.MethodHandles.Lookup class in Java SE 7 and later). This is useful in dynamic programming languages, as it provides capabilities that are not yet available in JSR 292. MethodHandle objects can be used to read from or write to a field. However, field updaters can perform atomic operations, write to non-volatile fields using volatile writes, perform lazy volatile writes, and read to non-volatile fields using volatile reads, things that MethodHandles cannot do directly.

You can create a MethodHandle on FieldUpdater.compareAndSet.
The only advantage I see to create a new API is to avoid the runtime 
check that is done each time compareAndSet is called.

> - To facilitate the implementation of JVM programming languages whose field access semantics differ from the Java Programming Language.
> The new field accessor APIs provide the following guarantees:
> - Static final fields are never written to through the new field accessor APIs
> - Writes to final instance fields through the new field accessors are not enabled by default
> - Security checks and immutability of final fields are enforced by default
> - Callers must have permission to disable security checks and final field immutability checks
> - Volatile and final fields are never written to through a non-volatile write
> - Reads to volatile fields through the new field accessor API's are normal volatile reads by default

Also note that you can use MethodHandle API to change the value of a 
final field.
Create a java.lang.reflect.Field, call setAccessible(true) and then use 


More information about the Concurrency-interest mailing list