Heap allocation reported to AllocationTracker may be later divided into several objects so it is incorrect to put the block as a new HeapObject into the map. We will match allocated block with actual HeapObjects later when iterating Heap (will be addressed in another patch). Since the objects are not assigned an id immediately after creation we need to call FindOrAddEntry when finding id for SharedFunctionInfo during stack crawling.
Removed hooks for tracking creation of AllocationMemento. AllocationMemento is not a HeapObject and should be considered as implementation overhead.
Renamed NewObjectEvent to AllocationEvent which is more precise in case of folded allocations and when a part of the new block becomes AllocationMemento.
BUG=None
LOG=N
R=loislo@chromium.org, mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/95283003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18151 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is initial implementation of allocation profiler.
Whenever new object allocation is reported to the HeapProfiler and allocation tracking is on we will capture current stack trace, add it to the collection of the allocation traces (a tree) and attribute the allocated size to the top JS function on the stack.
Format of serialized heap snapshot is extended to include information about recorded allocation stack traces.
This patch is r17301 plus a fix for the test crash in debug mode. The test crashed because we were traversing stack trace when just allocated object wasn't completely configured, in particular the map pointer was incorrect. Invalid Map pointer broke heap iteration required to find Code object for a given pc during stack traversal. The solution is to insert free space filler in the newly allocated block just before collecting stack trace.
BUG=chromium:277984,v8:2949
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/61893031
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17742 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is initial implementation of allocation profiler.
Whenever new object allocation is reported to the HeapProfiler and allocation tracking is on we will capture current stack trace, add it to the collection of the allocation traces (a tree) and attribute the allocated size to the top JS function on the stack.
Format of serialized heap snapshot is extended to include information about recorded allocation stack traces.
This patch is r17301 plus a fix for the test crash in debug mode. The test crashed because we were traversing stack trace when just allocated object wasn't completely configured, in particular the map pointer was incorrect. Invalid Map pointer broke heap iteration required to find Code object for a given pc during stack traversal. The solution is to insert free space filler in the newly allocated block just before collecting stack trace.
BUG=chromium:277984,v8:2949
R=hpayer@chromium.org, loislo@chromium.org
Review URL: https://codereview.chromium.org/34733004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17365 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is initial implementation of allocation profiler.
Whenever new object allocation is reported to the HeapProfiler and allocation tracking is on we will capture current stack trace, add it to the collection of the allocation traces (a tree) and attribute the allocated size to the top JS function on the stack.
Format of serialized heap snapshot is extended to include information about recorded allocation stack traces.
BUG=chromium:277984
R=hpayer@chromium.org, loislo@chromium.org
Review URL: https://codereview.chromium.org/27227005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17301 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
