> On 11 Apr 2014, at 21:04, Mike Duigou <mike.dui...@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 <marti...@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.dui...@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 >
