RFR: 8035284: (xs) Remove redundant null initialization

[Martin Buchholz]

I see now that the semantics of

private Foo foo = null;

and

private Foo foo;

are different, because in the first case foo may have been set to non-null
by other code textually "left" to the initialization to null.  Conceptually
a variable explicitly initialized to null is initialized twice - first the
initialization to null promised by the JVM, and then the explicit
initialization to null.  The compiler may be able to elide the assignment,
but only by doing an analysis of all possible executions. And for volatile
fields, it is reasonable (if you squint) to expect that a true volatile
store is performed even if the VM can prove that "this" does not escape the
constructor.

Change approved!  Still, it makes me sad.

We will also cleanse jsr166 sources of these redundant initializations.


On Fri, Apr 11, 2014 at 1:11 PM, Mike Duigou <mike.duigou at oracle.com> wrote:

> 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
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140411/a2421592/attachment.html>