[concurrency-interest] Elements in AtomicReferenceArray and AtomicReference[] both distinct?

Nathan Reynolds nathan.reynolds at oracle.com
Thu Aug 2 13:52:03 EDT 2012


In HotSpot, each thread can have a Thread Local Allocation Buffer 
(TLAB).  This allows the thread to allocate an object extremely fast 
(maybe 20 cycles).  When the TLAB is used up, the thread goes through a 
much more expensive process to get another TLAB.  When all of the TLABs 
are used up, GC is triggered.  Most of the time, if a thread allocates 2 
objects one after the other, then both objects will be located in memory 
next to each other (unless each is allocated from different TLABs).  
When GC moves the objects, they will most likely stay near each other.

AtomicReference[] can still suffer from false sharing.  If all of the 
elements (i.e. AtomicReference) are allocated by the same thread one 
after the other, then the elements will be laid out in RAM as if they 
were an array.  However, the false sharing won't be as severe since each 
AtomicReference has an object header.

For example, on HotSpot Windows 32-bit, the object header is 8 bytes and 
a reference is 4 bytes.  I guess an AtomicReference object consumes 16 
bytes in total (I haven't measured it).  Only 4 AtomicReference objects 
can share a 64-byte cache line. AtomicReferenceArray has an Object[] 
(?).  This means 16 elements can share a 64-byte cache line.  Thus, the 
false sharing is 4x worse for AtomicReferenceArray.

Should everyone stop using AtomicReferenceArrays and roll their own 
AtomicReference[] which uses padding to make sure each AtomicReference 
can't share a cache line?  No.  This will increase the memory bandwidth 
requirements and could have a negative impact.  Premature optimization 
or optimizing a microbenchmark will probably hurt overall performance.  
Make sure you are actually seeing a problem in some large benchmark or test.

Nathan Reynolds 
<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> | 
Consulting Member of Technical Staff | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
On 8/1/2012 9:03 AM, Chris Vest wrote:
> Hi Raph,
>
> You are more likely to run into false sharing (cache-line contention) 
> with AtomicReferenceArray, when threads concurrently write to element 
> indices that are close to each other, than you are with an array of 
> AtomicReference objects. On the other hand, the latter uses more memory.
>
> The implementation of ARA does not use locks:
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/atomic/AtomicReferenceArray.java?revision=1.42&view=markup
>
>
> On 1 August 2012 17:24, Raph Frank <raphfrk at gmail.com 
> <mailto:raphfrk at gmail.com>> wrote:
>
>     I always assumed that elements in an AtomicReferenceArray were
>     distinct.  Threads that accessed different elements would not
>     interfere.
>
>     This thread suggests otherwise, that the protection is at the entire
>     array level.
>
>     http://www.java-forums.org/threads-synchronization/25324-atomicreferencearray-t-equivalent-array-atomicreference-t.html
>
>     Which is correct, do an array of AtomicReferences give better
>     concurrency?
>     _______________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.oswego.edu
>     <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120802/db273ffa/attachment.html>


More information about the Concurrency-interest mailing list