RFR(XS): 8073954: Initialize _replaced_nodes in SafePoints.
kim.barrett at oracle.com
Thu Feb 26 18:15:19 UTC 2015
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.
> 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
_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.
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
More information about the hotspot-dev