Stack iterator takes return address based on the frame pointer (ebp) and detects JS frames based on value at fp + StandardFrameConstants::kMarkerOffset. So in order the iterator to work correctly this values should be already setup for the current function. Stack frame is constructed at the very beginning of JS function code and destroyed before return. If sample is taken before before the frame construction is completed or after it was destroyed the stack iterator will wrongly think that FP points at the current functions frame base and will skip callers frame. To avoid this we mark code ranges where stack frame doesn't exist and completely ignore such samples.
This fixes cctest/test-cpu-profiler/CollectCpuProfile flakiness.
BUG=v8:2628
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/14253015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14670 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
CPU profiler API is extended with methods that allow to retrieve individual samples from profile. Each sample is presented as a pointer to a node in the top-down profile tree. The samples will let us tie JS performance to time.
BUG=None
Review URL: https://codereview.chromium.org/12919002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13980 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Since symbols and strings share a common representation, most of this change is about consistently replacing 'String' with 'Name' in all places where property names are expected. In particular, no new logic at all is necessary for maps, property dictionaries, or transitions. :) The only places where an actual case distinction is needed have to do with generated type checks, and with conversions of names to strings (especially in logger and profiler).
Left in some TODOs wrt to the API: interceptors and native getters don't accept symbols as property names yet, because that would require extending the external v8.h.
(Baseline CL: https://codereview.chromium.org/12296026/)
R=verwaest@chromium.org,mstarzinger@chromium.org
BUG=v8:2158
Review URL: https://codereview.chromium.org/12330012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13811 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 will give us the ability to keep entries_ list sorted by id.
And based on that fact we will be able to use it for:
1) GetNodeById method and drop sorted version of entries list in HeapSnapshot;
2) building heap stats;
3) doing the fill stage instead of second iteration over heap.
BUG=none
TEST=none
R=yurys
Review URL: https://chromiumcodereview.appspot.com/10031032
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11259 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
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
