[concurrency-interest] The Atomic*FieldUpdater situation

Rémi Forax forax at univ-mlv.fr
Sat Jul 14 18:46:38 EDT 2012

On 07/14/2012 11:58 PM, Stanimir Simeonoff wrote:
>     The next question is how to guarantee that the update value as the
>     right type, otherwise you can
>     corrupt the memory by putting a String in an Integer field (and
>     you can't rely on generics for that).
> Absolutely true, it's not needed to java.lang.Object, which is a 
> start. C2 can eliminate redundant CHECKCAST since the class is a 
> constant, dunno if Class.isAssignableFrom enjoys the same treatment. 
> Hence, a simple class-gen will do the trick. Class-gen happen very 
> often w/ reflect, so I do not consider it too special. Again, when 
> System.ClassLoader is not present or the caller is from the bootstrap 
> loader that class-gen can be omitted.

Class-gen is not as cool as it seems, it uses a lot of memory (bytecode 
+ VM metadata) and
classloader/class unloading is really tricky. MethodHandle should be 
used instead, but from perf point of view
the JIT backend is still too young for this particular case, in fact, a 
MethodHandle.invoke() is exactly what we need.
And I really hope that at some point in the future j.l.r.Method will be 
re-written to use method handles instead.

As a meta-comment, if they're was a way to trap Java method call to 
transform them into invokedynamic,
all the problems mentioned above disappear because we will be in control 
of the callsite.

>         Since there would be a single subclass only instantiated in
>         the JVM there would be no performance loss from multi-site
>         invocations.
>     You don't care if there are several subclasses because you've put
>     your AtomicReferenceFieldUpdater in a static final field.
> True that, it can be proven it won't change, even if it's an interface.
> Stanimir


More information about the Concurrency-interest mailing list