[concurrency-interest] general performance question

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Thu Dec 22 03:47:29 EST 2011


Vitaly,

Yes, for C2 it's bytecodeInfo.cpp. And for C1 it's 
src/share/vm/c1/c1_GraphBuilder.cpp [1]. Surprisingly, there's 
C1-specific flag called InlineSynchronizedMethods (btw, true by default) :)

I did some brief source code archeology study (starting from 1.5) and 
didn't find any changes in how sync methods are inlined. So I expect it 
worked the same in Hotspot early days.

Regarding significance of byte code size on performance, I can't comment 
- I don't have any representative numbers ;-)

Best regards,
Vladimir Ivanov

[1] 
http://www.google.com/codesearch#Y_pa0sa9c2w/src/share/vm/c1/c1_GraphBuilder.cpp&q=src/share/vm/c1/c1_GraphBuilder.cpp&exact_package=http://hg.openjdk.java.net/jdk7/build/hotspot&l=3441


On 12/22/11 3:31 AM, Vitaly Davidovich wrote:
> Also I thought inlining heuristics were in bytecodeInfo.cpp? And at a
> cursory glance I don't see anything related to synch blocks - nice! I
> guess that makes the different byte code emitted difference possibly
> significant.
>
> On Dec 21, 2011 6:23 PM, "Vitaly Davidovich" <vitalyd at gmail.com
> <mailto:vitalyd at gmail.com>> wrote:
>
>     Thanks Vladimir, good to know.  Curiously, has this been the case
>     for a long time or something more or less recent? Was it added as
>     part of lock elimination/coarsening work?
>
>     On Dec 21, 2011 4:37 PM, "Vladimir Ivanov"
>     <vladimir.x.ivanov at oracle.com <mailto:vladimir.x.ivanov at oracle.com>>
>     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
>         <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
>         <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>
>             <mailto: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
>             <http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds>>
>             |
>                 Consulting Member of Technical Staff | 602.333.9091
>             <tel:602.333.9091> <tel: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>
>                 <mailto:Concurrency-interest at __cs.oswego.edu
>                 <mailto:Concurrency-interest at cs.oswego.edu>>
>                 http://cs.oswego.edu/mailman/__listinfo/concurrency-interest
>                 <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>
>             <mailto:Concurrency-interest at __cs.oswego.edu
>             <mailto:Concurrency-interest at cs.oswego.edu>>
>             http://cs.oswego.edu/mailman/__listinfo/concurrency-interest
>             <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
>             <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>


More information about the Concurrency-interest mailing list