R=vitalyr@chromium.org
BUG=none
TEST=none

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

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

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

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

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

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

objects retained by object groups and global handles.

This information is then used during heap snapshot generation
to provide a more complete memory picture.

This patch will be needed to fix https://bugs.webkit.org/show_bug.cgi?id=53659.

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

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

into heap snapshots non-HeapObjects. This is needed as a
preparation for adding DOM subtrees tracking.

BUG=none
TEST=none

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

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

the distance between bleeding edge and the gc branch minimal.
Review URL: http://codereview.chromium.org/5788002

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

As taking a snapshot of a large heap takes noticeable time, it's
good to be able to monitor and control it.

The change itself is small, big code deletes and additions are in
fact moves. The only significant change is simplification of
approximated retained sizes calculation algorithm.

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

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

This is intended for smoother migration to the new API in Chromium.
Also, aggregated heap snapshots can be used for cheaply obtaining
heap statistics, e.g. in tests.

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

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

To trace objects between snapshots, an external map of object tags is
maintained. After the first heap snapshot has been taken, the map is
updated by reporting object moves from the GC. If no snapshots were
taken, there is no overhead (except for flag checking).

I considered graph comparison algorithms that doesn't require using
object tags, but they are all of a high computational complexity, and
will still fail to detect object moves properly, even for trivial
cases, so using tags looks like unavoidable.

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

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

BUG=738
TBR=sgjesse@chromium.org

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

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

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

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

Remove messages.h from v8.h and include it explicitly in only the few places
it is needed.  Many files relied on getting handles-inl.h implicitly from
messages.h through v8.h, so include handles-inl.h explicitly in v8.h
instead.

Remove zone-inl.h from header files where it is not needed, can be replaced
by a forward declaration, or can be replaced by zone.h (specifically,
factory.h and heap.h).  Include zone.h or zone-inl.h in header files where
it was implicitly included via heap.h or factory.h.  Prefer zone.h over
zone-inl.h in header files where possible by including zone-inl.h in .cc
files.

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

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

if logging producers is turned off.
Review URL: http://codereview.chromium.org/500092

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

- account code objects in retainers profile;
- differentiate between function boilerplates and closures;
- simplify code;

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

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

Turned on with '--log-producers' flag, also needs '--noinline-new' (this is temporarily), '--log-code', '--log-gc'. Not all allocations are traced (I'm investigating.)

Stacks are stored using weak handles. Thus, when an object is collected, its allocation stack is deleted.

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

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

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

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

Also perform some refactoring.

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

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

Also, perform some refactoring to reuse common code between constructor and retainer profiles.

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

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

TBR=kasperl@chromium.org

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

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

TBR=sgjesse@chromium.org

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

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

The profile is taken together with constructors profile. In theory, it
should represent a complete heap graph. However, this takes a lot of memory,
so it is reduced to a more compact, but still useful form. Namely:

 - objects are aggregated by their constructors, except for Array and Object
   instances, that are too hetereogeneous;

 - for Arrays and Objects, initially every instance is concerned, but then
   they are grouped together based on their retainer graph paths similarity (e.g.
   if two objects has the same retainer, they are considered equal);

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

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