The heap profiler randomly crashed because of memory corruption caused
by unexpected heap objects layout changes occured between count and fill
passes. The changes lead the number of retainers counted on the first pass
did not match its number on the fill pass leading to the out of bounds
array access.
Besides that the mark bit scheme has been changed to a plain vector one in
dominators building algorithm. It is up to 4x faster because of smaller
memory access footprint.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/9594020
Patch from Alexei Filippov <alexeif@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10928 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 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/9463008
Patch from Alexei Filippov <alexeif@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10823 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Replace timestamps with affected bool vector. Timestamps could cause
some entries marked as affected on iteration i, to be recalculated
twice on iterations i and i+1. Which is redundant.
BUG=none
TEST=none
Review URL: https://chromiumcodereview.appspot.com/9467002
Patch from Alexei Filippov <alexeif@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10821 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
CPU-eating DOS attacks against node.js servers. Based on code from
Bert Belder. This version only solves the issue for those that compile
V8 themselves or those that do not use snapshots. A snapshot-based
precompiled V8 will still have predictable string hash codes.
Review URL: http://codereview.chromium.org/9086006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10330 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Replaced FIRST_PHANTOM_PROPERTY_TYPE by a predicate. Removed the (hopefully)
last default cases for switches on PropertyType. Benchmarks show that both
changes are performace-neutral.
Now every value of PropertyType should either be handled by an explicit case in
a switch or by an equality operator. Therefore, the C++ compiler should finally
be able to tell us which places to touch when changing PropertyType.
Review URL: http://codereview.chromium.org/8506004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9930 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
