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
Approximation is done by building a dominators tree for the heap graph.
Dominator nodes and retained sizes are serialized into JSON.
Removed:
- reachable size (it is useless, after all);
- HeapEntryCalculatedData (size is now stored in the node, retaining
paths in a hash map);
Review URL: http://codereview.chromium.org/5154007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5867 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Otherwise, retaned memory sizes are not precise. This increases size
of heap snapshot, I will deal with this later. Heap objects and
references previously missing in snapshot are now marked as 'hidden'.
That means, they not shown to user, but participate in sizes
calculation.
Other small changes:
- added 'shortcut' graph edges: e.g. to pin global objects on top
level;
- meta-information in JSON snapshot is no more double encoded.
Review URL: http://codereview.chromium.org/5139002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5849 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
HeapNumbers do consume memory, so it's worth dumping them. However, we
don't dump their values, as they are not as self-descriptive as values
of strings, and they will increase snapshot size. Storing heap numbers
values can be added if we will feel a sufficient demand for that.
InternalFields are used, e.g. for storing references to DOM nodes
event handlers.
Review URL: http://codereview.chromium.org/3769007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5635 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
during snapshot size optimization.
Sorry, now I figured out that the diff implementation itself was also
incorrect. Reachable nodes must be filtered from the beginning,
otherwise, an object that is already disconnected, but not discarded
yet, will not appear as a deleted (thankfully, this bug for some
reason had appeared on the x64 port.)
BUG=868
TEST=HeapSnapshotRootPreservedAfterSorting
Review URL: http://codereview.chromium.org/3531005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5570 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
to avoid storing serialized snapshot on VM, instead it is emitted
using output stream interface.
The size of JSON emitted is roughly equal to used heap size
(when stored as an ASCII string).
Now a whole heap snapshot can be serialized and transmitted outside
VM. This makes possible:
- implementing non-async UI for heap snapshots inspection;
- storing heap snapshots for further inspection;
- remote profiling (we can even implement a snapshotting mode
where a snapshot isn't even stored in VM, only transmitted --
good for mobile devices);
- creating tools for outside heap snapshots processing, e.g.
converting to HPROF.
Review URL: http://codereview.chromium.org/3311028
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5450 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
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
