It is achieved by:
1. skipping entries those dominators have already reached root.
2. processing only entries those retainers have changed their
dominators and skipping other entries.
3. removing extra memory indirection by making the dominators array
contain entry indices instead of entries themselves.
The dominators building time has dropped from ~4000 ms to ~200 ms
on gmail.com heap snapshot.
BUG=none
TEST=none
Review URL: https://chromiumcodereview.appspot.com/9372105
Patch from Alexei Filippov <alexeif@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10799 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
As example there are 'Detached DOM Tree' nodes in WebKit. It is very useful to be able to see all such
nodes grouped together. It can be done with help of some post processing but I did this explicitly
on v8 side because it is much faster. At the moment this kind of nodes has kNative type.
I'd like to hide these nodes from the Retainment View but I can filter them only by name.
BUG=none
TEST=HeapSnapshotRetainedObjectInfo
Review URL: https://chromiumcodereview.appspot.com/9323064
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10614 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The detailed heap snapshot has two groups of nodes. The first one
is the group for v8 heap nodes and the second one is the group for
native objects. At the moment we have two different sets of native
objects. There are 'Detached DOM trees' and 'Document DOM trees' type of objects.
I think it'd be nice to replace one group containing all native objects with
separate groups for different types of native objects.
BUG=none
TEST=HeapSnapshotRetainedObjectInfo
Review URL: https://chromiumcodereview.appspot.com/9223009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10528 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Each such string requires small amount of heap memory.
Heap snapshot generator copies all the strings into internal hash map for future use.
The each copy requires much more memory than original v8 string.
I made a workaround for this. The snapshot will copy only first 1024 symbols.
A simple drive-by fix was made for a performance problem in ToCString implementation.
BUG=v8:1816
TEST=none
Review URL: http://codereview.chromium.org/8509003
Patch from Ilya Tikhonovsky <loislo@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9928 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The preprocessor defines ENABLE_LOGGING_AND_PROFILING and ENABLE_VMSTATE_TRACKING has been removed as these where required to be turned on for Crankshaft to work. To re-enable reducing the binary size by leaving out heap and CPU profiler a new set of defines needs to be created.
R=ager@chromium.org
BUG=v8:1271
TEST=all
Review URL: http://codereview.chromium.org//7350014
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8622 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The main issue was due to multiple recompilations of functions. Now
code objects are grouped by function using SFI object address.
JSFunction objects are no longer tracked, instead we track SFI object
moves. To pick a correct code version, we now sample return addresses
instead of JSFunction addresses.
tools/{linux|mac|windows}-tickprocessor scripts differentiate
between code optimization states for the same function
(using * and ~ prefixes introduced earlier).
DevTools CPU profiler treats all variants of function code as
a single function.
ll_prof treats each optimized variant as a separate entry, because
it can disassemble each one of them.
tickprocessor.py not updated -- it is deprecated and will be removed.
BUG=v8/1087,b/3178160
TEST=all existing tests pass, including Chromium layout tests
Review URL: http://codereview.chromium.org/6551011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6902 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
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
