[concurrency-interest] AtomicInteger implementation

Yann Le Tallec ylt at letallec.org
Thu Feb 28 17:36:41 EST 2013


That makes sense. Thank you for your answer.

Regarding ADD vs. INC, it is in section 3.5.1.1 page 3-30 of the pdf
version of the optimisation manual [1]: "INC and DEC instructions should be
replaced with ADD or SUB instructions, because ADD and SUB overwrite all
flags, whereas INC and DEC do not, therefore creating false dependencies on
earlier instructions that set the flags."

If that is the case, it is strange that the JIT uses INC.

 [1]:
http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html


On 28 February 2013 22:23, Nathan Reynolds <nathan.reynolds at oracle.com>wrote:

>  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>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
>> 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);}
>>
>> Regards,
>> 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 listConcurrency-interest at cs.oswego.eduhttp://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/20130228/696030da/attachment-0001.html>


More information about the Concurrency-interest mailing list