[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 
updater classes?

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 
updater itself.

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?
-- 
- DML


More information about the Concurrency-interest mailing list