[concurrency-interest] general performance question

Vitaly Davidovich vitalyd at gmail.com
Wed Dec 21 18:31:59 EST 2011


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> 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>
> 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@**oracle.com <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
>>> >
>>>    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<Concurrency-interest at cs.oswego.edu> <mailto:
>>>> Concurrency-interest@**cs.oswego.edu<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<Concurrency-interest at cs.oswego.edu>
>>>    <mailto:Concurrency-interest@**cs.oswego.edu<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<Concurrency-interest at cs.oswego.edu>
>>> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111221/ed1ce896/attachment.html>


More information about the Concurrency-interest mailing list