RFR: 8035284: (xs) Remove redundant null initialization

[Mike Duigou]

I and others have tried to track down the compiler issue in which this change was made. If anyone can point us in the right direction it would be nice to reference that issue.

Mike

On Apr 11 2014, at 13:09 , Chris Hegarty <chris.hegarty at oracle.com> wrote:

> 
>> On 11 Apr 2014, at 21:04, Mike Duigou <mike.duigou at oracle.com> wrote:
>> 
>> Apparently javac did at elide the "extraneous" null initialization at one point and it was deemed to have been contrary to point #4 of the procedure in JLS 12.5 (http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.5-220-D)
> 
> I remember talking to Maurizio about this a few years ago. I think he mentioned something similar.
> 
> -Chris.
> 
>> 
>> Mike
>> 
>> 
>>> On Apr 11 2014, at 12:57 , Martin Buchholz <martinrb at google.com> wrote:
>>> 
>>> It's surprising that javac does not eliminate the redundant initializations to null.  Initializing to null has documentation value (suggesting that the constructor will not assign a value; null is a "valid" value).  How about fixing javac instead?
>>> 
>>> 
>>> On Fri, Apr 11, 2014 at 12:22 PM, Mike Duigou <mike.duigou at oracle.com> wrote:
>>> Hello all;
>>> 
>>> This is a simple cleanup changeset that removes redundant initialization of fields to null from a number of collection classes. These field initializations may seem cheap but they do have a cost:
>>> 
>>> - For volatile fields there is a measurable cost on some benchmarks for these extra initializations.
>>> 
>>> - Larger byte code in <init> methods.
>>> 
>>> - For transient fields the initialization is misleading since it does not occur on deserialization.
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8035284
>>> http://cr.openjdk.java.net/~mduigou/JDK-8035284/0/webrev/
>>> 
>>> Redundant null initializations in other components/packages will be handled in separate issues.
>>> 
>>> Mike
>>