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.