There have been multiple cases in the past where using Object::null()
as the initializer, even for non-Ptr fields, has caused nondeterministic
snapshot creation. In particular, this can happen if a non-Ptr field
is only used in some versions of an object but not others, and thus
there is no reason to worry about what the value of the field is during
runtime. Only when snapshotting can it become relevant that the field
value is a portion of the address of Object::null(), which can vary
over different runs.
Instead of initializing the entirety of allocated objects (outside
of a few rare cases) with Object::null(), only initialize the portion
of the object corresponding to object pointer fields (in most cases,
between from() and to() inclusively) to Object::null() and initialize
the rest of the object to 0.
With this change, the only special casing in Object::InitializeObject
that remains is to skip initialization for TypedData and Arrays when
the memory is guaranteed to be zero initialized and to initialize the
contents of Instructions objects with the break instruction, not 0.
Note that this behavior does not occur in the following cases, which
all involve copying an arbitrary object:
* Object::Clone(), which zero-initializes the contents of the object
in all cases. However, the contents of the original object are then
copied over before the thread can reach a safepoint.
* Inside the ObjectGraphCopier, which uses the old initialization
behavior. This is safe, as any GC-important fields are immediately
copied over, and the rest of the contents are eventually copied over
before the caller receives the root of the copied object graph.
TEST=ci
Issue: https://github.com/dart-lang/sdk/issues/52876
Change-Id: Ib09fc562a8b6af97b509b493eb2d64109230ec35
Cq-Include-Trybots: luci.dart.try:vm-linux-debug-x64-try,vm-linux-debug-x64c-try,vm-linux-release-x64-try,vm-aot-linux-product-x64-try,vm-aot-linux-release-x64-try,vm-aot-linux-debug-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312900
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
Tess Strickland
2f63acea22