[concurrency-interest] general performance question

Vitaly Davidovich vitalyd at gmail.com
Wed Dec 21 13:09:09 EST 2011


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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111221/61e81b18/attachment.html>


More information about the Concurrency-interest mailing list