[concurrency-interest] general performance question

Dr Heinz M. Kabutz heinz at javaspecialists.eu
Wed Dec 21 17:27:41 EST 2011


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
>


More information about the Concurrency-interest mailing list