Align double array backing store during compaction and mark-sweep promotion.

Align double array backing store during compaction and mark-sweep promotion.

1st (of 3) CL's to ensure complete alignment of FixedDoubleArrays.

TEST=
BUG=

[dusmil, 2013-10-22 16:33:20]

PTAL, this and 2 related CLs provide complete alignment of FixedDoubleArrays
which then allows a big MIPS performance improvement via
https://codereview.chromium.org/35463002.

[Paul Lind, 2013-11-06 17:24:10]

LGTM, but we need review from the v8 team, can one of you PTAL?

[Michael Starzinger, 2013-11-14 13:37:45]

Thanks for the patch. I understand the motivation of the change and agree that
mark-sweep collections should maintain double alignment. Unfortunately I am not
yet entirely sure about how to implement this in a clean way and prevent code
duplication at the different allocation sites in the GC. I will think about this
some more and try to come up with a fix for the missing alignment.

https://codereview.chromium.org/35103002/diff/20001/src/mark-compact.cc
File src/mark-compact.cc (right):

https://codereview.chromium.org/35103002/diff/20001/src/mark-compact.cc#newco...
src/mark-compact.cc:2021: allocation_size += kPointerSize;
Hmm, could this end up using more space in the to-space than was used in the
from-space? Imagine every object in the from-space survives and promotion fails.
Every object was allocated with the inline allocation sequence that doesn't
over-allocate to align. With this alignment strategy every object will consume
one additional word in to-space.

I realize that this is a highly constructed scenario, and that we already have
that problem with the existing EvacuateObject implementation. But it leads me to
believe that a better way of implementing the alignment within the GC would be
to make sure the top-pointer is aligned before we allocate.

https://codereview.chromium.org/35103002/diff/20001/src/mark-compact.cc#newco...
src/mark-compact.cc:2948: allocation_size += kPointerSize;
This might exceed Page::kMaxNonCodeHeapObjectSize.

[Paul Lind, 2013-11-14 16:40:06]

On 2013/11/14 13:37:45, Michael Starzinger wrote:
> Thanks for the patch. I understand the motivation of the change and agree that
> mark-sweep collections should maintain double alignment. 

Michael, thanks for your review comments, and I look forward to your further
thoughts on this. There is another double-alignment CL pending
(https://chromiumcodereview.appspot.com/35313002), not GC related, but part of
the same goal, to have FixedDoubleArrays aligned at all times. I'll add you as a
reviewer to that one as well. Thanks.

[dusmil, 2013-12-13 16:06:14]

https://codereview.chromium.org/35103002/diff/20001/src/mark-compact.cc
File src/mark-compact.cc (right):

https://codereview.chromium.org/35103002/diff/20001/src/mark-compact.cc#newco...
src/mark-compact.cc:2021: allocation_size += kPointerSize;
Yes, this is very unlikely, but it might happen. Currently, I think the only way
to keep allocation top aligned and to avoid this scenario is to round up object
sizes to multiple of 8, thus setting allocation granularity to 8 bytes, but this
will have impact on memory footprint. At least we can try the experiment for
MIPS only, as we will additionally get aligned heap numbers that way.

Regarding code duplication for alignment handling, it can be sorted out by
moving double alignment handling code in AllocateRaw routines and pass to the
additional flag, but this change will be more intrusive.

https://codereview.chromium.org/35103002/diff/20001/src/mark-compact.cc#newco...
src/mark-compact.cc:2948: allocation_size += kPointerSize;
According to the definition of Page::kMaxNonCodeHeapObjectSize double alignment
is taken into account.

static const int kMaxNonCodeHeapObjectSize =
      kNonCodeObjectAreaSize - kPointerSize;

So, this CHECK could be changed to CHECK(object_size <=
Page::kNonCodeObjectAreaSize) and move after alignment handling.

[dusmil, 2015-05-07 10:24:18]

Finally fixed in https://codereview.chromium.org/1130833002.

This can provide ~20% performance improvement in Navier-Stokes benchmark on
mips32.