When a snapshot is generated on a 64 bit architecture and then read into a 32 bit architecture, val…

When a snapshot is generated on a 64 bit architecture and then read into a 32 bit architecture, values which are Smi on the 64 bit architecture could potentially be converted to Mint objects, however since Smi values do not have any notion of canonical bits we lose that information when the object becomes a Mint.

Some of these values could be literal values and end up in the VM isolate heap. Later when these values are referenced in a constant list we try to ensure that all the objects in the list are canonical and try to canonicalize them. When these Mint objects are encountered they do not have the canonical bit set and canonicalizing them won't work as the VM heap is read only now. In these cases we clone the object into the isolate and then canonicalize it.

BUG=
R=johnmccutchan@google.com

Committed: https://github.com/dart-lang/sdk/commit/c8549e064e9262d4e68ce48fcc4059f0de184123

[siva, 2015-10-05 18:03:16]

asiva@google.com changed reviewers:
+ johnmccutchan@google.com

[srdjan, 2015-10-05 18:06:36]

srdjan@google.com changed reviewers:
+ srdjan@google.com

[srdjan, 2015-10-05 18:06:37]

DBC

https://codereview.chromium.org/1391433002/diff/1/runtime/vm/object.cc
File runtime/vm/object.cc (right):

https://codereview.chromium.org/1391433002/diff/1/runtime/vm/object.cc#newcod...
runtime/vm/object.cc:14484: // Create a canonical object in old space.
Maybe comment here briefly why this is necessary.

[Cutch, 2015-10-05 18:27:54]

LGTM but I wonder if Ivan's suggestion of just promoting mint-range smis at
snapshot read time might be cleaner?

[siva, 2015-10-05 21:51:06]

Agree it would be cleaner if we can turn all these Smis into canonical Mints
while reading the snapshot itself. Currently there are some boot strapping
issues that I need to work through (being able to call the regular object
allocation code while reading a snapshot) before this can be done.

So I suggest we use this patch until those boot strapping issues are addressed.

https://codereview.chromium.org/1391433002/diff/1/runtime/vm/object.cc
File runtime/vm/object.cc (right):

https://codereview.chromium.org/1391433002/diff/1/runtime/vm/object.cc#newcod...
runtime/vm/object.cc:14484: // Create a canonical object in old space.
On 2015/10/05 18:06:36, srdjan wrote:
> Maybe comment here briefly why this is necessary.

Done.

[siva, 2015-10-06 17:57:07]

Committed patchset #2 (id:20001) manually as
c8549e064e9262d4e68ce48fcc4059f0de184123 (presubmit successful).