[concurrency-interest] The Atomic*FieldUpdater situation

√iktor Ҡlang viktor.klang at gmail.com
Sun Jul 15 11:22:13 EDT 2012


On Sun, Jul 15, 2012 at 1:14 PM, David Holmes <davidcholmes at aapt.net.au>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,
√


>
> David
> -----
>
>
> > 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
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



-- 
Viktor Klang

Akka Tech Lead
Typesafe <http://www.typesafe.com/> - The software stack for applications
that scale

Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120715/9594c8a0/attachment.html>


More information about the Concurrency-interest mailing list