atom feed19 messages in edu.oswego.cs.concurrency-interestRe: [concurrency-interest] The Atomic...
FromSent OnAttachments
David M. LloydJul 14, 2012 11:01 am 
Doug LeaJul 14, 2012 11:17 am 
Stanimir SimeonoffJul 14, 2012 1:01 pm 
√iktor ҠlangJul 14, 2012 1:16 pm 
Rémi ForaxJul 14, 2012 2:20 pm 
Stanimir SimeonoffJul 14, 2012 2:58 pm 
Rémi ForaxJul 14, 2012 3:44 pm 
Doug LeaJul 15, 2012 3:37 am 
David HolmesJul 15, 2012 4:14 am 
√iktor ҠlangJul 15, 2012 8:22 am 
David M. LloydJul 15, 2012 9:19 am 
Jed Wesley-SmithJul 15, 2012 7:31 pm 
David HolmesJul 15, 2012 7:35 pm 
David M. LloydJul 15, 2012 7:43 pm 
David HolmesJul 15, 2012 7:52 pm 
Jason T. GreeneJul 20, 2012 11:42 am 
David HolmesJul 20, 2012 6:34 pm 
David M. LloydJul 22, 2012 1:47 pm 
Doug LeaJul 23, 2012 3:44 am 
Subject:Re: [concurrency-interest] The Atomic*FieldUpdater situation
From:Jed Wesley-Smith (
Date:Jul 15, 2012 7:31:29 pm

here's some further info on the subject:

On 16 July 2012 01:22, √iktor Ҡlang <> wrote:

On Sun, Jul 15, 2012 at 1:14 PM, David Holmes <>wrote:

David M. Lloyd writes:

What is the purpose of the access-time access check in the atomic field updater classes?

Do you mean the ensureProtectedAccess check?

This is to ensure that you can't get an updater for a protected inherited field in SubtypeA, then use that updater to access/modify the field in an instance of SubtypeB.

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.

Now you've lost me. Which access check is this? All of the methods do:

if (obj == null || obj.getClass() != tclass || cclass != null) fullCheck(obj);

where fullCheck is:

private void fullCheck(T obj) { if (!tclass.isInstance(obj)) throw new ClassCastException(); if (cclass != null) ensureProtectedAccess(obj); }

and ensureProtectedAccess is:

private void ensureProtectedAccess(T obj) { if (cclass.isInstance(obj)) { return; } throw new RuntimeException( new IllegalAccessException("Class " + cclass.getName() + " can not access a protected member of class " + tclass.getName() + " using an instance of " + obj.getClass().getName() ) ); }

So if everything is in the same class we don't do any additional checks.

Which is a huge issue in langs that don't do statics, like Scala, you end up having to have a Java superclass to hold the final statics and then implement the meaty part in Scala, which is a huge pain due to these defensive checks. A new @static annotation is on the way for Scala to try to work around this and to solve issues with libraries/frameworks that build on static members.

So I'm forced to either inherit Atomic* or go directly for Unsafe, and since there are no traits in Java, I almost always have to go Unsafe to have multiple fields.

Cheers, √

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?

-- Viktor Klang

Akka Tech Lead Typesafe <> - The software stack for applications that scale

Twitter: @viktorklang