[concurrency-interest] The Atomic*FieldUpdater situation
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
> 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.
More information about the Concurrency-interest