Add some interfaces to the GC that allow us to reserve space. This is needed...

Add some interfaces to the GC that allow us to reserve space.  This is needed
for partial snapshots.  After reserving space we can be sure that allocations
will happen linearly (no GCs and no free-list allocation).  This change also
contains the start of the partial snapshot support, which, however is not yet
completed or tested.

Committed: http://code.google.com/p/v8/source/detail?r=3584

[Mads Ager (chromium), 2010-01-12 14:17:49]

Does calling ReserveSpace really ensure that you can allocate that many bytes? 
What about unusable holes at the end of pages?  Also, size of large objects
depends on the granularity of the OS allocation routines, so the slack there
needs depend on that?

http://codereview.chromium.org/545026/diff/1/10
File src/heap.h (right):

http://codereview.chromium.org/545026/diff/1/10#newcode1060
src/heap.h:1060: HeapObject* target,
Missing space on this line and the next.

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

http://codereview.chromium.org/545026/diff/1/7#newcode1852
src/spaces.cc:1852: bytes_left_to_reserve -= Page::kPageSize;
Do we need some slack here?  Allocating just enough pages for |bytes| bytes does
not ensure that you can actually allocate them if there is a hole that you
cannot use at the end of one of the pages.

http://codereview.chromium.org/545026/diff/1/7#newcode1866
src/spaces.cc:1866: // We add a slack-factor of 2 in order to have space for the
remembered
Is a factor of 2 enough?  I would guess that this really needs to scale with the
allocation granularity of the operating system.  I believe that we allocate a
minimum of 64k for a large object on Windows even though the object might only
be slightly larger than 8k.

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

http://codereview.chromium.org/545026/diff/1/4#newcode311
src/spaces.h:311: // snapshots.  It returns true of space was reserved or false
if a GC is
of space -> if space

[Erik Corry, 2010-01-12 14:24:24]

The caller is supposed to precompensate for memory that is wasted at the end of
pages.  This seems onerous, but it's the sort of thing the snapshot code already
needs to keep track of so it's not too bad.  I will update the comments
accordingly.

As for the large object space that is a little messy.  In practice, a context
snapshot won't contain many large objects and it may be OK to just fudge it by
using an AlwaysAllocate scope around large object allocations. At least there
are no issues with non-contiguous allocation.

[Mads Ager (chromium), 2010-01-12 14:34:59]

On 2010/01/12 14:24:24, Erik Corry wrote:
> The caller is supposed to precompensate for memory that is wasted at the end
of
> pages.  This seems onerous, but it's the sort of thing the snapshot code
already
> needs to keep track of so it's not too bad.  I will update the comments
> accordingly.

OK

> As for the large object space that is a little messy.  In practice, a context
> snapshot won't contain many large objects and it may be OK to just fudge it by
> using an AlwaysAllocate scope around large object allocations. At least there
> are no issues with non-contiguous allocation.

As we discussed, the factor of 2 should be enough since the OS granularity is
not part of our accounting.

LGTM