BUG=

Review URL: https://codereview.chromium.org/11415070

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13063 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This implements incremental scanning of large objects using a progress
bar in the page header of such objects. Note that this requires forward
white to gray transitions in the write barrier and hence is disabled by
default for now.

R=ulan@chromium.org,hpayer@chromium.org

Review URL: https://codereview.chromium.org/11362246

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12978 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

The patch introduces CommittedPhysicalMemory function to
the Heap class that reports committed *physical* memory acquired
for the heap from the OS.
It is important because some OSes may defer actual committment on e.g.
first access to the region.
So reporting just plain committed size led to various weird artifacts
like showing V8 allocated memory higher than the whole process
private size.

BUG=v8:2191

Review URL: https://codereview.chromium.org/11066118
Patch from Alexei Filippov <alph@chromium.org>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12793 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: https://chromiumcodereview.appspot.com/11188031

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12746 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=mstarzinger@chromium.org
BUG=v8:2120

Review URL: https://codereview.chromium.org/11118018

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12713 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This reverts commit r12619.

BUG=

Review URL: https://chromiumcodereview.appspot.com/11029023

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12660 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Original message: Implement committed physical memory stats for Linux.
This had to be reverted because it crashes when compiled into Chromium
due to the sandbox not allowing the mincore call.

R=verwaest@chromium.org
BUG=v8:2191

Review URL: https://codereview.chromium.org/11023010

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12640 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

The patch introduces CommittedPhysicalMemory function to the Heap class
that reports committed *physical* memory acquired from the OS.
It is important because some OSes may postpone actual commitment on e.g.
first access to the previously committed region.
So reporting just plain committed size led to various weird artifacts
like DevTools showing V8 allocated memory higher than the whole process
private size.

BUG=v8:2191

Review URL: https://codereview.chromium.org/10961042
Patch from Alexei Filippov <alph@chromium.org>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12625 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

mark stack overflow.  This is a reland of r12609 -
https://chromiumcodereview.appspot.com/10959011 - but
this time VisitPointers has been fixed (it used to assume
that the first slot was on the first page of a large object).
Review URL: https://chromiumcodereview.appspot.com/10996018

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12619 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

at which we are hitting expensive write barrier operations,
not just on the rate of allocation.
Review URL: https://chromiumcodereview.appspot.com/10974003

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12618 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

due to crashes in unbox-double-arrays.js test.
Review URL: https://chromiumcodereview.appspot.com/10996017

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12610 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

mark stack overflow.
Review URL: https://chromiumcodereview.appspot.com/10959011

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12609 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

the speed of deserializing code.  The current startup
time improvement for V8 is around 6%, but code deserialization
is speeded up disproportionately, and we will soon have more
code in the snapshot.
* Removed support for deserializing into large object space.
  The regular pages are 1Mbyte now and that is plenty.  This
  is a big simplification.
* Instead of reserving space for the snapshot we actually
  allocate it now.  This removes some special casing from
  the memory management and simplifies deserialization since
  we are just bumping a pointer rather than calling the
  normal allocation routines during deserialization.
* Record in the snapshot how much we need to boot up and
  allocate it instead of just assuming that allocations in
  a new VM will always be linear.
* In the snapshot we always address an object as a negative
  offset from the current allocation point.  We used to
  sometimes address from the start of the deserialized data,
  but this is less useful now that we have good support for
  roots and repetitions in the deserialization data.
* Code objects were previously deserialized (like other
  objects) by alternating raw data (deserialized with memcpy)
  and pointers (to external references, other objects, etc.).
  Now we deserialize code objects with a single memcpy,
  followed by a series of skips and pointers that partially
  overwrite the code we memcopied out of the snapshot.
  The skips are sometimes merged into the following
  instruction in the deserialization data to reduce dispatch
  time.
* Integers in the snapshot were stored in a variable length
  format that gives a compact representation for small positive
  integers.  This is still the case, but the new encoding can
  be decoded without branches or conditional instructions,
  which is faster on a modern CPU.
Review URL: https://chromiumcodereview.appspot.com/10918067

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12505 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=mstarzinger@chromium.org

Review URL: https://chromiumcodereview.appspot.com/10579041

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11921 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Release the mapping as whole if commit failed to avoid leaking virtual address space.

R=mstarzinger@chromium.org
BUG=chromium:118625

Review URL: https://chromiumcodereview.appspot.com/10260012

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11471 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This makes the test-alloc test case more robust against changes to the
initial heap size. It correctly simulates a full space now instead of
trying to fill the space up by allocating filler objects.

R=svenpanne@chromium.org
TEST=cctest/test-alloc

Review URL: https://chromiumcodereview.appspot.com/10071003

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11284 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

http://codereview.chromium.org/9179012 was trying to achieve.  This
time I am going for 80% of the benefit with around 5% of the complexity.

It works by reducing the size of the first page in each space.  Unlike the
previous change there is no attempt to grow pages, we just allocate more
full-sized pages when we need more memory.  For this reason the first pages are
not quite as small (compare
http://codereview.chromium.org/9179012/diff/1/src/snapshot.h with the changes
in spaces.cc in this cl):  We want to be able to do a little bit of allocation
before we have to add a full-sized page to the space.
Review URL: https://chromiumcodereview.appspot.com/9950048

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11203 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

object space. Before, it was a link-list based look-up, and make this function
a little bit 'hot' from profile point.

BUG=v8:853
TEST=

Review URL: https://chromiumcodereview.appspot.com/9634005
Patch from Zhongping Wang <kewpie.w.zp@gmail.com>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11084 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Fields introduced with guarding code space pages (area_start_, area_end_) were not correctly handled which lead to errors in StoreBuffer filtering.

R=mstarzinger@chromium.org
TEST=mozilla/data/js1_5/GC/regress-203278-2.js

Review URL: https://chromiumcodereview.appspot.com/9600020

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10927 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Split executable memory chunks into two pieces: header with all metadata (protection: RW) and body (protection: RWX). Separate header from metadata with a guard page and add a guard page after the page body.

R=erik.corry@gmail.com
BUG=http://crbug.com/115151

Review URL: https://chromiumcodereview.appspot.com/9452002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10809 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: https://chromiumcodereview.appspot.com/9362014

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10646 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Increase slots buffer chain length to 15 to make compaction more aggressive and usefull.

Pass gc and collector selection reasons to GCTracer to allow more meaningull --gc-trace.

Print fragmentation of spaces that we do not compact.

R=erik.corry@gmail.com

Review URL: https://chromiumcodereview.appspot.com/9323007

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10601 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

on Windows.
Review URL: https://chromiumcodereview.appspot.com/9104039

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10569 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This is a recommit of https://chromiumcodereview.appspot.com/9289047
with changes noted in comments in the codereview tool.
Review URL: https://chromiumcodereview.appspot.com/9233050

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10562 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

issues on 64 bit.
Review URL: https://chromiumcodereview.appspot.com/9295047

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10544 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This is a recommit of http://codereview.chromium.org/9179012
after fixing what turned out to be unrelated out-of-memory
errors.
That was a rebase of http://codereview.chromium.org/9017009/
Review URL: https://chromiumcodereview.appspot.com/9289047

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10542 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: https://chromiumcodereview.appspot.com/9117035

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10491 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=mstarzinger@chromium.org
BUG=
TEST=

Review URL: https://chromiumcodereview.appspot.com/9178021

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10426 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Empty but unswept pages could cause the unswept_free_bytes counter to
to be off in case heap gets shrunk and page gets released before it was
swept properly.

R=vegorov@chromium.org
BUG=v8:1893

Review URL: https://chromiumcodereview.appspot.com/9241010

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10421 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

test failures.
Review URL: http://codereview.chromium.org/9178014

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10417 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

improvement in boot time memory usage.
Review URL: http://codereview.chromium.org/9242008

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10415 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

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/
Review URL: http://codereview.chromium.org/9179012

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10413 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/9231009

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10407 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/9139051

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10399 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This improves the heap size estimation by not counting lazy swept pages
as completely allocated but use their live bytes counter instead.

R=vegorov@chromium.org
BUG=v8:1893
TEST=cctest/test-heap/TestSizeOfObjects

Review URL: http://codereview.chromium.org/9173001

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10383 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

a mark-sweep.  We have a soft limit on old space size, which is designed to
trigger an old-space collection when we hit it.  Unfortunately although the
soft limit had already triggered an old space collection, the soft limit was
preventing objects from new space from being promoted.  For every promotion
candidate we were checking 3 different ways to allocate in old space before
giving up and putting the object in the other semispace.  This change allows
the promoted objects to go to old space and also makes us more eager to
sweep a page before trying other ways to find space for an object.
Review URL: http://codereview.chromium.org/8748005

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10092 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Limit the number of pages that are compacted in a given GC.
Review URL: http://codereview.chromium.org/8692002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10084 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Our Heap::FreeQueuedChunks generates fake inner chunks in large object
pages queued for freeing, so that StoreBuffer::Filter can recognize them
as pages to be freed. This also relies on MemoryChunk::Contains to work
properly, which is why the size field needs to be initialized as well.

R=vegorov@chromium.org
BUG=v8:1817
TEST=mozilla/js1_5/Regress/regress-360969-05

Review URL: http://codereview.chromium.org/8536009

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9964 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Heap::Shrink is called from EnsureFromSpaceIsCommitted at the very start of the GC. At this moment live bytes counts on pages are in inconsistent states. Some pages might have been already swept but have not been yet reached by an incremental marker (or incremental marker is not in progress) and have live bytes count set to 0. Thus we can't rely only on LiveBytes to determine which pages can be released to the OS.

R=mstarzinger@chromium.org
BUG=100414

Review URL: http://codereview.chromium.org/8507038

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9953 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=erik.corry@gmail.com

Review URL: http://codereview.chromium.org/8477030

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9932 ce2b1a6d-e550-0410-aec6-3dcde31c8c00