[concurrency-interest] The Atomic*FieldUpdater situation

Jed Wesley-Smith jwesleysmith at atlassian.com
Sun Jul 15 22:31:29 EDT 2012


here's some further info on the subject:

http://stackoverflow.com/questions/5574502/how-do-i-get-an-atomicreferencefieldupdater-from-a-scala-companion-object

On 16 July 2012 01:22, √iktor Ҡlang <viktor.klang at gmail.com> wrote:

>
>
> 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
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120716/6b29db4f/attachment.html>


More information about the Concurrency-interest mailing list