Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io
vitalyd at gmail.com
Fri Aug 24 13:11:25 UTC 2012
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.
Sent from my phone
On Aug 24, 2012 9:02 AM, "Doug Lea" <dl at 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.
More information about the core-libs-dev