Make new space iterable when transitioning double array to objects

Make new space iterable when transitioning double array to objects

R=hpayer@chromium.org
BUG=

Committed: https://code.google.com/p/v8/source/detail?r=20603

[Hannes Payer (out of office), 2014-04-08 14:19:27]

https://codereview.chromium.org/228643002/diff/1/src/arm/codegen-arm.cc
File src/arm/codegen-arm.cc (right):

https://codereview.chromium.org/228643002/diff/1/src/arm/codegen-arm.cc#newco...
src/arm/codegen-arm.cc:610: __ mov(r0, Operand(Smi::FromInt(0)));
In allocation folding, we store the one_pointer_filler_map to uninitialized
memory when we verify the heap. Either do that to stay in sync with allocation
folding implementation or install a free_space_map with the given size. I
actually would prefer option B. Then you do not have to loop over the array.

https://codereview.chromium.org/228643002/diff/1/test/mjsunit/regress/regress...
File test/mjsunit/regress/regress-transition-elements-heap-verification.js
(right):

https://codereview.chromium.org/228643002/diff/1/test/mjsunit/regress/regress...
test/mjsunit/regress/regress-transition-elements-heap-verification.js:7:
%SetAllocationTimeout(1000000, 1000000);
The test looks super fragile, but there is probably nothing we can do here.

[Jarin, 2014-04-08 21:04:16]

Yes, it is worrisome that the test is so brittle - it has to trigger GC on heap
number allocation. In fact, the test case only repros for x64, so we do not have
full test coverage here. I did some sanity checks by simulating the GC manually
(simply by jumping to the gc_cleanup label rather than calling
AllocateHeapNumber), and then checking in the debugger that we fill the array
with the expected value.

On the plus side, it should be safe for release mode because the code only
affects heap verification mode.

https://codereview.chromium.org/228643002/diff/1/src/arm/codegen-arm.cc
File src/arm/codegen-arm.cc (right):

https://codereview.chromium.org/228643002/diff/1/src/arm/codegen-arm.cc#newco...
src/arm/codegen-arm.cc:610: __ mov(r0, Operand(Smi::FromInt(0)));
On 2014/04/08 14:19:27, Hannes Payer wrote:
> In allocation folding, we store the one_pointer_filler_map to uninitialized
> memory when we verify the heap. Either do that to stay in sync with allocation
> folding implementation or install a free_space_map with the given size. I
> actually would prefer option B. Then you do not have to loop over the array.

Replaced with one_pointer_filler_map (although I am still not completely sure
what is the advantage over Smi 0 - the array is dead, so any valid value should
be fine).

As for option B - we would have to calculate the size again and that seems to be
more error prone than just using the counter in r3 to finish the initialization
of the array. Performance does not matter here. The case is rare and we are
verifying heap - that dominates the running time anyway.

https://codereview.chromium.org/228643002/diff/1/test/mjsunit/regress/regress...
File test/mjsunit/regress/regress-transition-elements-heap-verification.js
(right):

https://codereview.chromium.org/228643002/diff/1/test/mjsunit/regress/regress...
test/mjsunit/regress/regress-transition-elements-heap-verification.js:7:
%SetAllocationTimeout(1000000, 1000000);
On 2014/04/08 14:19:27, Hannes Payer wrote:
> The test looks super fragile, but there is probably nothing we can do here.

Indeed, I am not sure how to make it better (it took embarrassingly long time to
minimize the original ClusterFuzz test case to the somewhat manageable repro
here).

[Hannes Payer (out of office), 2014-04-09 08:22:06]

LGTM

[Jarin, 2014-04-09 09:50:24]

Committed patchset #2 manually as r20603 (presubmit successful).