[concurrency-interest] The Atomic*FieldUpdater situation
David M. Lloyd
david.lloyd at redhat.com
Sat Jul 14 14:01:59 EDT 2012
What is the purpose of the access-time access check in the atomic field
If I construct an atomic field updater, to me, this should be exactly
equivalent to having an accessible=true Field instance. If I want to
manage the visibility of that instance, I will restrict access to the
The problem, as I am sure you are all well aware, is that when the
updater classes are used on an object instance which is subclassed, even
if the field being updated, the field updater, and the method calling
into the field updater all exist on the base class and are private, an
expensive access check has to occur.
Even when the class is final, the access check is still expensive
relative to the operation itself!
I mean I'm using field updaters in the first place because I can't
afford to have a jillion Atomic* objects floating around; obviously
performance is critical here. And to add to this problem, you can't
even rely on using Unsafe, even though it's becoming more and more
prevalent in JDKs, as some platforms may not have atomic 64-bit
operations, and there's no way I can see to test for that other than
relying on the AtomicLong implementation to be similar to OpenJDK's.
Is there any recourse to solve this issue?
More information about the Concurrency-interest