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

[Vitaly Davidovich]

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
>
>
>
>