[concurrency-interest] general performance question

√iktor Ҡlang viktor.klang at gmail.com
Wed Dec 21 13:43:06 EST 2011


Would be nice to allow for:

synchronized class Foo {
 ...constructor + all non-private methods are synchronized.
}

On Wed, Dec 21, 2011 at 7:09 PM, Vitaly Davidovich <vitalyd at gmail.com>wrote:

> I agree that it's unfortunate but I think it's still the case today (so
> even adding dummy locals/temps that will surely optimize out may bump a
> method out of inlining).
>
> My guess is that this is done to reduce compilation time.  Since
> compilation is done on a method at a time basis, the compiler has to decide
> quickly whether to inline or not and it's of course faster if it uses
> simple (I.e. quick) heuristics rather than potentially generating two
> different flavors (inlined callee and not) and pitching one away.
>
> Having said that, would be great to know the real reason from someone on
> the compiler team.
> On Dec 21, 2011 12:42 PM, "Ruslan Cheremin" <cheremin at gmail.com> wrote:
>
>> I've heard about this issue before, but I can't believe it is still
>> actual -- doesn't modern JIT smart enough to count inlining threshold
>> by generated machine code instructions (which I believe will be the
>> same in both cases), and not on source bytecodes?
>>
>> 2011/12/21 Vitaly Davidovich <vitalyd at gmail.com>:
>> > 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
>> >
>> > 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 | Consulting Member of Technical Staff | 602.333.9091
>> >> Oracle PSR Engineering | 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
>> >> 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
>
>


-- 
Viktor Klang

Akka Tech Lead
Typesafe <http://www.typesafe.com/> - Enterprise-Grade Scala from the
Experts

Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111221/f47bb406/attachment.html>


More information about the Concurrency-interest mailing list