[concurrency-interest] The Atomic*FieldUpdater situation
stanimir at riflexo.com
Sat Jul 14 17:58:57 EDT 2012
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.
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest