The reason of that is a number of cons strings in the app.
The app constructs a json string and as a result v8 heap has
a very long chain of cons strings.
Profiler counts all these strings as plain String objects and
assign the content of the strings as node names.
It required O(n^2) time and O(n^2) memory.
Solution: I introduced two new types, kConsString and kSliced string.
They do not use the content of the string for names. So the problem disappeared.
The heap profiler usability problem will be solved on Blink side.
BUG=285770
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/23460027
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16611 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Added instance method on v8::Isolate for retrieving instance of v8::HeapProfiler for that isolate. All static methods of v8::HeapProfiler are deprecated, corresponding instance methods are added to v8::HeapProfiler.
All static methods on v8::internal::HeapProfiler were converted into instance ones.
BUG=None
Review URL: https://codereview.chromium.org/12907006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13997 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
I tried to limit the use of v8::Isolate::GetCurrent() and v8::internal::Isolate::Current() as much as possible, but sometimes this would have involved restructuring tests quite a bit, which is better left for a separate CL.
BUG=v8:2487
Review URL: https://codereview.chromium.org/12716010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13953 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Minor cleanups on the way, e.g. making sure that we never use something after an allocation failed. Style question: Should we switch to some kind of MUST_USE_RESULT-style to ensure that we handle failures consistently? Not sure...
BUG=v8:2576
Review URL: https://codereview.chromium.org/12867002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13946 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Prevously v8 put a link to each context variable into a function where
the variable is visible.
Because of that if there are N functions sharing a context having M variables
then N*M links were created for the snapshot.
The fix makes v8 to put the links into the context object.
BUG=145687
TEST=test-heap-snapshot/ManyLocalsInSharedContext
Review URL: https://codereview.appspot.com/7715044
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13936 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Unified parameter order of CreateHandle with the rest of v8 on the way. A few
Isolate::Current()s had to be introduced, which is not nice, and not every place
will win a beauty contest, but we can clean this up later easily in smaller steps.
Review URL: https://codereview.chromium.org/12300018
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13717 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL adds multiple things:
Transition arrays do not directly point at their descriptor array anymore, but rather do so via an indirect pointer (a JSGlobalPropertyCell).
An ownership bit is added to maps indicating whether it owns its own descriptor array or not.
Maps owning a descriptor array can pass on ownership if a transition from that map is generated; but only if the descriptor array stays exactly the same; or if a descriptor is added.
Maps that don't have ownership get ownership back if their direct child to which ownership was passed is cleared in ClearNonLiveTransitions.
To detect which descriptors in an array are valid, each map knows its own NumberOfOwnDescriptors. Since the descriptors are sorted in order of addition, if we search and find a descriptor with index bigger than this number, it is not valid for the given map.
We currently still build up an enumeration cache (although this may disappear). The enumeration cache is always built for the entire descriptor array, even if not all descriptors are owned by the map. Once a descriptor array has an enumeration cache for a given map; this invariant will always be true, even if the descriptor array was extended. The extended array will inherit the enumeration cache from the smaller descriptor array. If a map with more descriptors needs an enumeration cache, it's EnumLength will still be set to invalid, so it will have to recompute the enumeration cache. This new cache will also be valid for smaller maps since they have their own enumlength; and use this to loop over the cache. If the EnumLength is still invalid, but there is already a cache present that is big enough; we just initialize the EnumLength field for the map.
When we apply ClearNonLiveTransitions and descriptor ownership is passed back to a parent map, the descriptor array is trimmed in-place and resorted. At the same time, the enumeration cache is trimmed in-place.
Only transition arrays contain descriptor arrays. If we transition to a map and pass ownership of the descriptor array along, the child map will not store the descriptor array it owns. Rather its parent will keep the pointer. So for every leaf-map, we find the descriptor array by following the back pointer, reading out the transition array, and fetching the descriptor array from the JSGlobalPropertyCell. If a map has a transition array, we fetch it from there. If a map has undefined as its back-pointer and has no transition array; it is considered to have an empty descriptor array.
When we modify properties, we cannot share the descriptor array. To accommodate this, the child map will get its own transition array; even if there are not necessarily any transitions leaving from the child map. This is necessary since it's the only way to store its own descriptor array.
Review URL: https://chromiumcodereview.appspot.com/10909007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12492 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
in anticipation of the upcoming lexical global scope.
Mostly automatised as:
for FILE in `egrep -ril "global[ _]?context" src test/cctest`
do
echo $FILE
sed "s/Global context/Native context/g" <$FILE >$FILE.0
sed "s/global context/native context/g" <$FILE.0 >$FILE.1
sed "s/global_context/native_context/g" <$FILE.1 >$FILE.2
sed "s/GLOBAL_CONTEXT/NATIVE_CONTEXT/g" <$FILE.2 >$FILE.3
sed "s/GlobalContext/NativeContext/g" <$FILE.3 >$FILE
rm $FILE.[0-9]
done
R=mstarzinger@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10832342
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12325 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The serialized node structure currently holds an index
of its first containment edge in the edges array.
The index can be quite big (up to 7 digits for large snapshots).
The patch changes the serialization format to pass
node containment edge count instead. For most nodes the count
is just a single digit number.
This reduces serialized snapshot size and therefore its transfer time.
Review URL: https://chromiumcodereview.appspot.com/10534008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11728 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This allowed the following changes:
- heap profiler now makes one pass less over the heap.
- HeapEntriesMap does not allocate EntryInfo per each entry.
- there's no need for an extra pass to set indexes before serialization.
As a result snapshot taking time has reduced up to 2x times.
Review URL: https://chromiumcodereview.appspot.com/10353010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11531 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The stats data have only count field at the moment.
A constantly growing array of integers also can be a reason of a leak.
Ans we have to have a way to detect such kind of leaks.
Drive by fix:
FindObject and AddEntry were replaced with FindEntry/FindOrAddEntry pair.
BUG=none
TEST=HeapSnapshotObjectsStats
Review URL: https://chromiumcodereview.appspot.com/10086004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11327 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch changes the signature of the v8::HeapGraphNode::GetRetainedSize method, but it's not used in Chromium, and it should be easy for other clients (if any) to adjust to this change.
BUG=none
TEST=none
Review URL: https://chromiumcodereview.appspot.com/9466014
Patch from Alexei Filippov <alexeif@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10846 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
As of dominators and retained sizes calculation take quite small time now
comparing to the main passes, it is worth to exclude these from progress
indicator. Now the indicator smoothly runs to 100%, while previously
it ran to 50% and then instantly jumped to 100%.
BUG=none
TEST=none
Review URL: https://chromiumcodereview.appspot.com/9465010
Patch from Alexei Filippov <alexeif@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10831 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
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
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
