[concurrency-interest] AtomicInteger implementation

Nathan Reynolds nathan.reynolds at oracle.com
Thu Feb 28 17:23:16 EST 2013


Given that the backport was resolved on 11/7/2012, I kind of doubt it 
was done in time for HotSpot 7u10.  7u11, 13 and 15 are security 
releases and hence won't have this fix.  7u12 and 14 were skipped. I 
hope this means that the next non-security HotSpot release (7u16?) will 
have the backport.

It seems strange that ADD 1 would be any faster or slower than INC on 
Intel x86.  Each instruction is decoded into one or more µops.  I would 
think both of these instructions would translate to the same µops.  In 
fact, ADD 1 will generate more code bytes than "inc".  So, from a cache 
performance perspective, "inc" should be faster.  I wonder what the 
explanation is for this.

Nathan Reynolds 
<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> | 
Architect | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
On 2/28/2013 3:15 PM, Yann Le Tallec wrote:
> I see. On JDK 7u11, running with PrintAssembly on, it looks like the 
> JIT does compile the code as is (possibly not treated as an intrinsic 
> method in that version?). As you explained:
> - incementAndGet translates into an INC
> - addAndGet translates into an ADD,1.
>
> However, according to Intel optimisation guidelines for x86, ADD,1 can 
> be faster than INC. A quick and dirty micro benchmark actually shows 
> that addAndGet(1) is fairly consistently 2-5% faster than 
> incrementAndGet (intel i5 - 64bit) post JIT compilation.
>
> Hence the question ;-)
>
>
> On 28 February 2013 21:53, Nathan Reynolds <nathan.reynolds at oracle.com 
> <mailto:nathan.reynolds at oracle.com>> wrote:
>
>     Good question.
>
>     For Hotspot x86, it doesn't matter.  HotSpot has intrinsics for
>     these methods.  So, on x86 they compile down to a single atomic
>     instruction.
>
>     For weaker JITs, increment by 1 can be much faster since it is a
>     constant and there can be an instruction on the processor for
>     incrementing.  This statement assumes that addAndGet(1) wouldn't
>     be inlined.
>
>     Nathan Reynolds
>     <http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> |
>     Architect | 602.333.9091 <tel:602.333.9091>
>     Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
>     On 2/28/2013 2:29 PM, Yann Le Tallec wrote:
>>     Hello,
>>
>>     all the code of |incrementAndGet| (in JDK 7) but one line is
>>     identical to|addAndGet|.
>>     What is the reason why the code has been duplicated instead of
>>     implementing |incrementAndGet| as:
>>     |public  final  int  incrementAndGet()  {
>>          return  addAndGet(1);
>>     }
>>     |
>>     |R|egards,
>>     Yann
>>     |-----
>>
>>
>>     |
>>     |For reference, the two methods:
>>
>>     |
>>     |public  final  int  addAndGet(int  delta)  {
>>          for  (;;)  {
>>              int  current=  get();
>>              int  next=  current+  delta;          // Only difference
>>              if  (compareAndSet(current,  next))
>>                  return  next;
>>          }
>>     }
>>
>>     public  final  int  incrementAndGet()  {
>>          for  (;;)  {
>>              int  current=  get();
>>              int  next=  current+  1;              // Only difference
>>              if  (compareAndSet(current,  next))
>>                  return  next;
>>          }
>>     }|
>>
>>
>>     _______________________________________________
>>     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
>     <mailto: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/20130228/a61b038e/attachment.html>


More information about the Concurrency-interest mailing list