Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io (original) (raw)

Vitaly Davidovich vitalyd at gmail.com
Fri Aug 24 12:53:51 UTC 2012

In response to a similar question a few months ago, Tom Rodriguez mentioned that c2 is not really susceptible to these redundant stores when making inlining decisions. I guess c1 (and interpreter of course) might be but then in those cases one's not getting max optimization anyway.

John Rose mentioned that the inlining decision making should be fixed for cases where it's susceptible to these types of bytecodes (presumably c1).

So it sounds like avoiding these locals is basically trying to work around current compiler limitations, rather than something more fundamental.

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.

Sent from my phone On Aug 24, 2012 6:45 AM, "Doug Lea" <dl at cs.oswego.edu> wrote:

Rémi Forax wrote:

Hi Dan, I'm not sure to like the fact that you introduce some local variables just to get ride of some warnings given that Hotspot compilers are sometimes sensitive to that. I think this practice should be discussed on this list before committing this changeset.

Yes. We discussed this during the last warnings cleanup. If javac cannot provide a means of shutting up these kinds of warnings without changing the emitted bytecode, then warning-free-compiles should not be required within JDK. (We hit a lot of warnings in j.u.c anyway because of uses of Unsafe that have no pure-java equivalents.) so is it a good idea to add a temporary local variable to fix a generics warning or should @SuppressWarnings should be set on the whole method ? We end up doing this this too often as a workaround. -Doug

More information about the core-libs-dev mailing list