[concurrency-interest] AtomicReferenceFieldUpdater vs Unsafe

√iktor Ҡlang viktor.klang at gmail.com
Thu Nov 17 07:49:00 EST 2011


On Thu, Nov 17, 2011 at 1:37 PM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 11/17/11 06:10, √iktor Ҡlang wrote:
>
>> Right now it feels like if you're doing high-perf concurrency in this
>> sense you
>> have to choose between:
>>
>> A) Cache-trashing (and extra memory usage) because you went with
>> AtomicLong/Ref
>> whatnot
>> B) CPU overhead caused by Atomic*Updaters and if you do any inheritance
>> you'll
>> get even more checks each call (and extra mem usage due to padding).
>> C) Sacrifice cross-platform because you had to drop down to Unsafe to get
>> the
>> correct machinecode emitted.
>>
>>
> Yes.
>
> The main underlying problem is a fundamental one: Java bytecodes
> support only two field read/write operations (getField/putField),
> plus an implicit mode argument for volatiles. However, there is no
> casField, or special r/w modes like releaseField. One level up,
> there is no syntax for "lvalue" operations on fields. So the
> only options are to directly invoke these lvalue operations
> via Unsafe, which require that you know the address of the field,
> or to use Updaters, that don't require the address, but must
> perform type checks and security checks that you have access to the
> field.
>
> No one knows of any good alternatives. We tried for Java7
> to reduce need for either option by proposing Fences that
> would at least emulate the different memory modes, but that's
> also problematic enough to not be worth adopting.
>
> It's not hard to imagine some nicer syntax to support
> these operations (as in a.someField.compareAndSet(x, y))
> and also to perform class-loading-time validations (similarly
> to "quickening") and/or using invokeDynamic. But these matters
> never attain high enough priority when people consider syntax
> enhancements.
>
> Portability of Unsafe constructions is not really a problem.
> We frequently communicate with all production JVM implementors
> to help ensure that they are correctly supported.
>

Alright, that's a good clarification, I've always avoided it from
compatibility reasons.
Is this case the same with Android?

Cheers,
√


>
> -Doug
>
>
>
> ______________________________**_________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.**oswego.edu <Concurrency-interest at cs.oswego.edu>
> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>



-- 
Viktor Klang

Akka Tech Lead
Typesafe <http://www.typesafe.com/> - Enterprise-Grade Scala from the
Experts

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


More information about the Concurrency-interest mailing list