Reduce boot-up memory use of V8.

Reduce boot-up memory use of V8.
Reduce signal sender thread stack size to 32k.
Commit partial old-space pages to reduce minimum memory use.
This is a rebase of http://codereview.chromium.org/9017009/
Committed: http://code.google.com/p/v8/source/detail?r=10413

[Vyacheslav Egorov (Chromium), 2012-01-16 17:02:54]

lgtm

http://codereview.chromium.org/9179012/diff/1/src/spaces-inl.h
File src/spaces-inl.h (right):

http://codereview.chromium.org/9179012/diff/1/src/spaces-inl.h#newcode260
src/spaces-inl.h:260: ASSERT(new_top >= Page::FromAddress(new_top -
1)->ObjectAreaStart());
FromAllocationTop instead of FromAddress

http://codereview.chromium.org/9179012/diff/1/src/spaces.cc
File src/spaces.cc (right):

http://codereview.chromium.org/9179012/diff/1/src/spaces.cc#newcode410
src/spaces.cc:410: // alignment.
Code below does not mention map space at all and is generic.

http://codereview.chromium.org/9179012/diff/1/src/spaces.cc#newcode419
src/spaces.cc:419: // This will waste the space for one map per doubling of the
page size until
Code is generic and does not reference map space directly.

http://codereview.chromium.org/9179012/diff/1/src/spaces.cc#newcode602
src/spaces.cc:602: Page* MemoryAllocator::AllocatePage(intptr_t
object_area_size,
object_area_size should really be comitted_object_area_size

http://codereview.chromium.org/9179012/diff/1/src/spaces.cc#newcode823
src/spaces.cc:823: reserved_page_size - last_page->size() >= size_in_bytes &&
I feel uncomfortable when arithmetic expression is not enclosed in parens in
comparison.

http://codereview.chromium.org/9179012/diff/1/src/spaces.cc#newcode1972
src/spaces.cc:1972: cur = (*cur) == NULL ? cur : (*cur)->next_address()) {
*cur == NULL ? NULL : ...

for better readability.

http://codereview.chromium.org/9179012/diff/1/src/spaces.h
File src/spaces.h (right):

http://codereview.chromium.org/9179012/diff/1/src/spaces.h#newcode1504
src/spaces.h:1504: virtual int ObjectAlignment() { return kPointerSize; }
kObjectAlignment instead of kPointerSize?

http://codereview.chromium.org/9179012/diff/1/src/spaces.h#newcode2378
src/spaces.h:2378: virtual int ObjectAlignment() { return object_size_in_bytes_;
}
for this to be object alignment we have to guarantee that start of object area
is appropriately aligned. are we at least asserting that?

[Vyacheslav Egorov (Chromium), 2012-01-16 17:20:53]

more comments

http://codereview.chromium.org/9179012/diff/1/src/spaces.cc
File src/spaces.cc (right):

http://codereview.chromium.org/9179012/diff/1/src/spaces.cc#newcode411
src/spaces.cc:411: uintptr_t end_int = old_end - ObjectAreaStart();
variable name is wrong. it's size, not end.

http://codereview.chromium.org/9179012/diff/1/src/spaces.cc#newcode412
src/spaces.cc:412: uintptr_t aligned_end_int =
ditto

http://codereview.chromium.org/9179012/diff/1/src/spaces.cc#newcode414
src/spaces.cc:414: if (aligned_end_int < end_int) {
!= instead of < for readability

[Erik Corry, 2012-01-17 07:48:12]

http://codereview.chromium.org/9179012/diff/1/src/spaces.cc
File src/spaces.cc (right):

http://codereview.chromium.org/9179012/diff/1/src/spaces.cc#newcode1972
src/spaces.cc:1972: cur = (*cur) == NULL ? cur : (*cur)->next_address()) {
On 2012/01/16 17:02:54, Vyacheslav Egorov wrote:
> *cur == NULL ? NULL : ...
> 
> for better readability.

It may be more readable, but it will also crash :-)

[Erik Corry, 2012-01-17 11:37:22]

http://codereview.chromium.org/9179012/diff/1/src/spaces-inl.h
File src/spaces-inl.h (right):

http://codereview.chromium.org/9179012/diff/1/src/spaces-inl.h#newcode260
src/spaces-inl.h:260: ASSERT(new_top >= Page::FromAddress(new_top -
1)->ObjectAreaStart());
On 2012/01/16 17:02:54, Vyacheslav Egorov wrote:
> FromAllocationTop instead of FromAddress

Done.

http://codereview.chromium.org/9179012/diff/1/src/spaces.cc
File src/spaces.cc (right):

http://codereview.chromium.org/9179012/diff/1/src/spaces.cc#newcode410
src/spaces.cc:410: // alignment.
On 2012/01/16 17:02:54, Vyacheslav Egorov wrote:
> Code below does not mention map space at all and is generic.

Done.

http://codereview.chromium.org/9179012/diff/1/src/spaces.cc#newcode411
src/spaces.cc:411: uintptr_t end_int = old_end - ObjectAreaStart();
On 2012/01/16 17:20:53, Vyacheslav Egorov wrote:
> variable name is wrong. it's size, not end.

Done.

http://codereview.chromium.org/9179012/diff/1/src/spaces.cc#newcode412
src/spaces.cc:412: uintptr_t aligned_end_int =
On 2012/01/16 17:20:53, Vyacheslav Egorov wrote:
> ditto

Done.

http://codereview.chromium.org/9179012/diff/1/src/spaces.cc#newcode414
src/spaces.cc:414: if (aligned_end_int < end_int) {
On 2012/01/16 17:20:53, Vyacheslav Egorov wrote:
> != instead of < for readability

Done.

http://codereview.chromium.org/9179012/diff/1/src/spaces.cc#newcode419
src/spaces.cc:419: // This will waste the space for one map per doubling of the
page size until
On 2012/01/16 17:02:54, Vyacheslav Egorov wrote:
> Code is generic and does not reference map space directly.

Done.

http://codereview.chromium.org/9179012/diff/1/src/spaces.cc#newcode602
src/spaces.cc:602: Page* MemoryAllocator::AllocatePage(intptr_t
object_area_size,
On 2012/01/16 17:02:54, Vyacheslav Egorov wrote:
> object_area_size should really be comitted_object_area_size

Done.

http://codereview.chromium.org/9179012/diff/1/src/spaces.cc#newcode823
src/spaces.cc:823: reserved_page_size - last_page->size() >= size_in_bytes &&
On 2012/01/16 17:02:54, Vyacheslav Egorov wrote:
> I feel uncomfortable when arithmetic expression is not enclosed in parens in
> comparison. 

Done.

http://codereview.chromium.org/9179012/diff/1/src/spaces.h
File src/spaces.h (right):

http://codereview.chromium.org/9179012/diff/1/src/spaces.h#newcode1504
src/spaces.h:1504: virtual int ObjectAlignment() { return kPointerSize; }
On 2012/01/16 17:02:54, Vyacheslav Egorov wrote:
> kObjectAlignment instead of kPointerSize?

Done.

http://codereview.chromium.org/9179012/diff/1/src/spaces.h#newcode2378
src/spaces.h:2378: virtual int ObjectAlignment() { return object_size_in_bytes_;
}
On 2012/01/16 17:02:54, Vyacheslav Egorov wrote:
> for this to be object alignment we have to guarantee that start of object area
> is appropriately aligned. are we at least asserting that?

No, the alignment is relative to the ObjectAreaStart at the moment.