[concurrency-interest] AtomicInteger implementation

Stanimir Simeonoff stanimir at riflexo.com
Thu Feb 28 17:38:53 EST 2013


The INC doesn't update the carry flag and can cause partial (un)updated
stalls: "Partial flags stalls" -
http://www.agner.org/optimize/microarchitecture.pdf (page58)
INC is shorter than ADD and can be of use, though. Since it doesn't affect
carry flag in can be hidden between adds/subs and consecutive carry flag
checks.

Stanimir


On Fri, Mar 1, 2013 at 12:23 AM, 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
>>
>>
>
>
> _______________________________________________
> 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/20130301/3313d88a/attachment-0001.html>


More information about the Concurrency-interest mailing list