I figured you did, but wanted to check. :) So the perf hit was with c2 compilation? Were you able to check the assembly (or enable inlining printing in hotspot) and see that lack of inlining (and whatever further opto that enabled) was the difference by simply adding a local or two? I'm legitimately curious here because if that's the case and this was on a somewhat recent hotspot build, it sort of goes against what TomR seemed to have been saying.
I agree with you that even javac should be able to remove this code, but it's disappointing if an optimizing JIT cannot handle it. Thanks Sent from my phone On Aug 24, 2012 9:02 AM, "Doug Lea" <d...@cs.oswego.edu> wrote: > Vitaly Davidovich wrote: > > So it sounds like avoiding these locals is basically trying to work >> around current compiler limitations, rather than something more fundamental. >> > > If javac did even a smidgen of optimization, this problem would > also go away. > > > >> I'm also curious if someone has actually noticed any perf degradation in >> hot code when adding locals like this (Doug? :)). If not (but perf tests >> were done), then I'm not sure it's worth worrying about. >> > > Of course, I have measured actual performance problems -- otherwise > I would not be bringing up this issue :-) Not every case is a > problem, but there are some cases that matter, and it is not a > good idea to invite people to rewrite, just for the sake of warning > suppression, code that explicitly chose not to introduce redundant locals. > > -Doug >
