RFR(XS): 8073954: Initialize _replaced_nodes in SafePoints.

[Kim Barrett]

On Feb 26, 2015, at 6:48 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> please review this tiny fix in the C2 compiler.  I please need a sponsor.
> 
> The field _replaced_node added to SafePoints in "8026796: Make replace_in_map() on parent maps generic"
> is not initialized to NULL.  As the memory is pre-set to 0, this doesn't cause immediate problems.
> But we saw lots of sporadic failures in our nightly tests of SAP JVM with the debug build, where memory
> in Arenas is zapped to 0xab.  We also saw rare failures with the opt builds.
> 
> https://bugs.openjdk.java.net/browse/JDK-8073954
> http://cr.openjdk.java.net/~goetz/webrevs/8073954-replNd/webrev/
> 
> 8026796 was downported to 8u40, so it's wrong there, too.

I've no problem with the change, per se.  However, I don't understand
the motivation for the change.

  "The field _replaced_node added to SafePoints in "8026796: Make
  replace_in_map() on parent maps generic" is not initialized to
  NULL."

_replaced_nodes is of type ReplacedNodes, which is a class type with
user-defined constructors (in this case, only a default constructor).
Note that it is not a pointer type, it is a nested object.

Not mentioning _replaced_nodes in the ctor-initializer (old code)
causes it to be <it>default initialized</it>. (C++03 12.6.2/4)

Including _replaced_nodes with an empty initializer list (proposed
change) causes it to be <it>value initialized</it>.  (C++03 12.6.2/3)

For a class type with a user-defined constructor, <it>value
initialization</it> and <it>default initialization</it> are the same;
both forms of initialization call the class's default constructor.
(C++03 8.5/5)

So with or without this change, _replaced_nodes should be initialized
via a call to its default constructor.  And that default constructor
directly initializes the pointer member to NULL.

In other words, I don't think this code change leads to any program
execution change.