RFR: 8035284: (xs) Remove redundant null initialization

Chris Hegarty chris.hegarty at oracle.com
Fri Apr 11 20:09:31 UTC 2014


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



More information about the core-libs-dev mailing list