[concurrency-interest] general performance question

Sergey Kuksenko skuksenko at gmail.com
Thu Dec 22 03:19:56 EST 2011


You may look at slides 32-34 here
http://people.apache.org/~shade/talks/j1-Oct2011-21682-benchmarking.pdf


On Thu, Dec 22, 2011 at 2:27 AM, Dr Heinz M. Kabutz
<heinz at javaspecialists.eu> wrote:
> My benchmark shows in most cases a small performance gain when you use an
> inner synchronized block.  However, the difference is really very small and
> is only in contended locks.  Uncontended locks are optimized away, so that
> does not count.
>
> On my 8-core machine, I call the methods lots of times with random values
> from a pre-filled array to stop the HotSpot compiler from eliminating my
> code.
>
> If the synchronized block is inside the method, we have the following test
> duration in average and standard deviation.  Times are in ms.  Small numbers
> are good, large numbers bad.  High standard deviation means the results are
> all over the place.
>
> 1 Thread:        20 (1.8)
> 2 Threads:    465 (53)
> 4 Threads:    889 (170)
> 8 Threads:    958 (137)
> 16 Threads:  629 (69)
> 32 Threads:  578 (66)
>
> When the whole method is synchronized:
>
> 1 Thread:        20 (0.5)
> 2 Threads:    488 (45)
> 4 Threads:    920 (145)
> 8 Threads:    1037 (90)
> 16 Threads:  612 (70)
> 32 Threads:  645 (74)
>
> However, as much as I would love these results to prove that my initial
> theoretical explanation was right, I think it's too close to call.  Neither
> is great.  If you want good scalability (which is the *only* performance
> reason you'd care about this) then you want to rather try to avoid locking
> altogether and use non-blocking synchronization constructs.
>
> I hope this helped.  My test code and raw results are available on demand.
>
>
> Regards
>
> Heinz
> --
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun Java Champion
> IEEE Certified Software Development Professional
> http://www.javaspecialists.eu
> Tel: +30 69 72 850 460
> Skype: kabutz
>
>
> On 12/21/11 11:37 PM, Vladimir Ivanov wrote:
>>
>> Vitaly,
>>
>> No, synchronized attribute doesn't prevent method from being inlined by
>> JIT compiler in Hotspot. Lock coarsening(redundant lock elimination)
>> optimization [1] [2] in C2 greatly benefits from this.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> [1]
>> http://java.sun.com/performance/reference/whitepapers/6_performance.html#2.1.2
>> [2]
>> http://www.google.com/codesearch#Y_pa0sa9c2w/src/share/vm/opto/callnode.cpp&l=1213
>>
>> On 12/21/11 9:33 PM, Vitaly Davidovich wrote:
>>>
>>> IIRC, synch on method generates less bytecode but that would only matter
>>> if the method was on the bytecode size boundary for inlining (I believe
>>> default is 35 byte codes), but i think synchronization already prevents
>>> inlining as a heuristic.
>>>
>>> On Dec 21, 2011 11:48 AM, "Nathan Reynolds" <nathan.reynolds at oracle.com
>>> <mailto:nathan.reynolds at oracle.com>> wrote:
>>>
>>>    Use javap to check the bytecode output from both.  From a
>>>    performance perspective, I don't think it shouldn't matter.
>>>    However, from an API perspective it matters.  Let's say you derive
>>>    the class and implement someMethod.  If the synchronized keyword is
>>>    on the method, then Eclipse or FindBugs could be configured to warn
>>>    you that the overridden method doesn't declare synchronized.  The
>>>    tool suggests that this means the overridden method is not correctly
>>>    synchronized.  On the other hand, "synchronized(this)" will trigger
>>>    Eclipse or FindBugs to warn you that the code is synchronizing on a
>>>    publicly accessible object.  This means that if another piece of
>>>    code synchronizes on the object then there might be an unintended
>>>    scalability problem.
>>>
>>>    Nathan Reynolds
>>>    <http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> |
>>>    Consulting Member of Technical Staff | 602.333.9091 <tel:602.333.9091>
>>>    Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
>>>
>>>    On 12/21/2011 8:45 AM, Jha, Navin wrote:
>>>>
>>>>    Is there an advantage to do:
>>>>
>>>>    someMethod(...) {
>>>>             synchronized(this) {
>>>>                     ................
>>>>                     ................
>>>>                     ................
>>>>             }
>>>>    }
>>>>
>>>>    instead of:
>>>>    synchronized someMethod(...) {
>>>>    ................
>>>>    ................
>>>>    ................
>>>>    }
>>>>
>>>>    Even when the entire method needs to be synchronized? I understand in
>>>> general it is a good practice to use synchronized blocks since more often
>>>> than not only certain lines need to be synchronized.
>>>>
>>>>    -Navin
>>>>
>>>>    _______________________________________________
>>>>    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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



-- 
Best regards,
Sergey Kuksenko



More information about the Concurrency-interest mailing list