- 26 Jan, 2016 1 commit
-
-
alph authored
It allows embedder to inject a stack sample on demand. BUG=chromium:579191 LOG=N Review URL: https://codereview.chromium.org/1631043002 Cr-Commit-Position: refs/heads/master@{#33527}
-
- 22 Jan, 2016 1 commit
-
-
ofrobots authored
Revert "Revert of [profiler] Implement POC Sampling Heap Profiler (patchset #12 id:220001 of https://codereview.chromium.org/1555553002/ )" This reverts commit 77df8659. BUG= Review URL: https://codereview.chromium.org/1618693004 Cr-Commit-Position: refs/heads/master@{#33473}
-
- 21 Jan, 2016 2 commits
-
-
ofrobots authored
Revert of [profiler] Implement POC Sampling Heap Profiler (patchset #12 id:220001 of https://codereview.chromium.org/1555553002/ ) Reason for revert: The random nature of the tests caused the following buildbot to fail: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/4724/steps/Check/logs/stdio Original issue's description: > [profiler] Implement POC Sampling Heap Profiler > > This implements a proof-of-concept sampling based heap profiler inspired by > tcmalloc's heap profiler [1] and Go's mprof/memprofile [2]. > > The basic idea is the sample allocations using a randomized Poisson process. At > any point in time we can cheaply request the set of live sample objects that > should be a representative sample of heap. Samples include stack-traces from the > allocation sites, making this an effective tool for memory leak debugging. > > Unlike AllocationTracking, this is intended to be cheap and usable online in > production. > > The proof-of-concept is only sampling new-space allocations at this point. > Support for sampling paged space and native allocations is anticipated in the > future. > > [1] http://goog-perftools.sourceforge.net/doc/heap_profiler.html > [2] http://blog.golang.org/profiling-go-programs > > Committed: https://crrev.com/e5a9947811db9c9e23557dbad27f8b8a349b3262 > Cr-Commit-Position: refs/heads/master@{#33448} TBR=jochen@chromium.org,alph@chromium.org,hpayer@chromium.org,yangguo@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1615173002 Cr-Commit-Position: refs/heads/master@{#33449}
-
ofrobots authored
This implements a proof-of-concept sampling based heap profiler inspired by tcmalloc's heap profiler [1] and Go's mprof/memprofile [2]. The basic idea is the sample allocations using a randomized Poisson process. At any point in time we can cheaply request the set of live sample objects that should be a representative sample of heap. Samples include stack-traces from the allocation sites, making this an effective tool for memory leak debugging. Unlike AllocationTracking, this is intended to be cheap and usable online in production. The proof-of-concept is only sampling new-space allocations at this point. Support for sampling paged space and native allocations is anticipated in the future. [1] http://goog-perftools.sourceforge.net/doc/heap_profiler.html [2] http://blog.golang.org/profiling-go-programs Review URL: https://codereview.chromium.org/1555553002 Cr-Commit-Position: refs/heads/master@{#33448}
-
- 03 Sep, 2015 1 commit
-
-
mstarzinger authored
R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1318863004 Cr-Commit-Position: refs/heads/master@{#30554}
-
- 06 Jul, 2015 1 commit
-
-
jochen authored
BUG=v8:4131 R=bmeurer@chromium.org LOG=n Review URL: https://codereview.chromium.org/1224623004 Cr-Commit-Position: refs/heads/master@{#29473}
-
- 03 Jun, 2015 1 commit
-
-
bbudge authored
LOG=N BUG=v8:4124 Review URL: https://codereview.chromium.org/1153373003 Cr-Commit-Position: refs/heads/master@{#28797}
-
- 09 Apr, 2015 1 commit
-
-
thakis authored
gcc rejects the following snippet, clang rejects it in -std=c++11 mode: namespace A { template<class T> class C {}; } namespace B { template class A::C<int>; } Indeed, the C++ standard says in 14.7.2p2 "An explicit instantiation shall appear in an enclosing namespace of its template", so cl.exe is incorrect to allow this. Just move the instantiation out of the v8 namespace to fix. No intended behavior change. Fixes building with clang-cl on Windows. BUG=chromium:475643 LOG=N TBR=svenpanne@chromium.org Review URL: https://codereview.chromium.org/1073903002 Cr-Commit-Position: refs/heads/master@{#27721}
-
- 08 Apr, 2015 1 commit
-
-
loislo authored
BUG=chromium:452067 LOG=n Committed: https://crrev.com/baf927ff5115ec62a6dad684b9232ed9d3960e3a Cr-Commit-Position: refs/heads/master@{#27626} Review URL: https://codereview.chromium.org/1045753002 Cr-Commit-Position: refs/heads/master@{#27674}
-
- 07 Apr, 2015 2 commits
-
-
machenbach authored
Revert of CpuProfiler: public API for deopt info in cpu profiler. (patchset #6 id:150001 of https://codereview.chromium.org/1045753002/) Reason for revert: [Sheriff] Breaks compile here: http://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20nosnap%20-%20shared/builds/6115 Original issue's description: > CpuProfiler: public API for deopt info in cpu profiler. > > BUG=chromium:452067 > LOG=n > > Committed: https://crrev.com/baf927ff5115ec62a6dad684b9232ed9d3960e3a > Cr-Commit-Position: refs/heads/master@{#27626} TBR=alph@chromium.org,jkummerow@chromium.org,svenpanne@chromium.org,yurys@chromium.org,loislo@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:452067 Review URL: https://codereview.chromium.org/1062053004 Cr-Commit-Position: refs/heads/master@{#27628}
-
loislo authored
BUG=chromium:452067 LOG=n Review URL: https://codereview.chromium.org/1045753002 Cr-Commit-Position: refs/heads/master@{#27626}
-
- 26 Mar, 2015 1 commit
-
-
yurys authored
Before this patch the embedder could assign timestamp to the last interval after calling GetHeapStats. This would be slightly different from the timstamps assigned by v8 internally and written into heap snapshot. This patch allow to avoid this small discrepancy by returning timestamp along with last heap stats update. BUG=chromium:467222 LOG=Y Review URL: https://codereview.chromium.org/1037803002 Cr-Commit-Position: refs/heads/master@{#27466}
-
- 16 Mar, 2015 1 commit
-
-
yurys authored
BUG=chromium:465651 LOG=Y Review URL: https://codereview.chromium.org/997583004 Cr-Commit-Position: refs/heads/master@{#27208}
-
- 10 Mar, 2015 2 commits
-
-
yurys authored
None of these fields is used in Blink. Embedder always can implement them using existing API. BUG=chromium:465651 LOG=Y Review URL: https://codereview.chromium.org/983833006 Cr-Commit-Position: refs/heads/master@{#27113}
-
yurys authored
BUG=None LOG=Y Review URL: https://codereview.chromium.org/992193002 Cr-Commit-Position: refs/heads/master@{#27097}
-
- 30 Jan, 2015 2 commits
-
-
Benedikt Meurer authored
This reverts commit 6a4c0a3b and commit 0deaa4b6 for breaking GCC bots. TBR=svenpanne@chromium.org Review URL: https://codereview.chromium.org/893533003 Cr-Commit-Position: refs/heads/master@{#26342}
-
bmeurer authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/888613002 Cr-Commit-Position: refs/heads/master@{#26340}
-
- 06 Nov, 2014 1 commit
-
-
svenpanne@chromium.org authored
The idea behind of this solution is to use the existing "relocation info" instead of consumption the CodeLinePosition events emitted by the V8 compilers. During generation code and relocation info are generated simultaneously. When code generation is done you each code object has associated "relocation info". Relocation information lets V8 to mark interesting places in the generated code: the pointers that might need to be relocated (after garbage collection), correspondences between the machine program counter and source locations for stack walking. This patch: 1. Add more source positions info in reloc info to make it suitable for source level mapping. The amount of data should not be increased dramatically because (1) V8 already marks interesting places in the generated code and (2) V8 does not write redundant information (it writes a pair (pc_offset, pos) only if pos is changed and skips other). I measured it on Octane benchmark - for unoptimized code the number of source positions may achieve 2x ('lin_solve' from NavierStokes benchmark). 2. When a sample happens, CPU profiler finds a code object by pc, then use its reloc info to match the sample to a source line. If a source line is found that hit counter is increased by one for this line. 3. Add a new public V8 API to get the hit source lines by CDT CPU profiler. Note that it's expected a minor patch in Blink to pack the source level info in JSON to be shown. 4.Add a test that checks how the samples are distributed through source lines. It tests two cases: (1) relocation info created during code generation and (2) relocation info associated with precompiled function's version. Patch from Denis Pravdin <denis.pravdin@intel.com>; R=svenpanne@chromium.org, yurys@chromium.org Review URL: https://codereview.chromium.org/682143003 Patch from Weiliang <weiliang.lin@intel.com>. Cr-Commit-Position: refs/heads/master@{#25182} git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25182 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 02 Oct, 2014 2 commits
-
-
yurys@chromium.org authored
Revert of Extend CPU profiler with mapping ticks to source lines (patchset #3 id:40001 of https://codereview.chromium.org/616963005/) Reason for revert: It broke layout test fast/events/window-onerror-02.html, error column reported by window.onerror is now wrong (I believe it is because of the change in full-codegen): http://build.chromium.org/p/client.v8/builders/V8-Blink%20Linux%2064%20%28dbg%29/builds/652 Original issue's description: > Extend CPU profiler with mapping ticks to source lines > > The idea behind of this solution is to use the existing "relocation info" instead of consumption the CodeLinePosition events emitted by the V8 compilers. > During generation code and relocation info are generated simultaneously. > When code generation is done you each code object has associated "relocation info". > Relocation information lets V8 to mark interesting places in the generated code: the pointers that might need to be relocated (after garbage collection), > correspondences between the machine program counter and source locations for stack walking. > > This patch: > 1. Add more source positions info in reloc info to make it suitable for source level mapping. > The amount of data should not be increased dramatically because (1) V8 already marks interesting places in the generated code and > (2) V8 does not write redundant information (it writes a pair (pc_offset, pos) only if pos is changed and skips other). > I measured it on Octane benchmark - for unoptimized code the number of source positions may achieve 2x ('lin_solve' from NavierStokes benchmark). > > 2. When a sample happens, CPU profiler finds a code object by pc, then use its reloc info to match the sample to a source line. > If a source line is found that hit counter is increased by one for this line. > > 3. Add a new public V8 API to get the hit source lines by CDT CPU profiler. > Note that it's expected a minor patch in Blink to pack the source level info in JSON to be shown. > > 4.Add a test that checks how the samples are distributed through source lines. > It tests two cases: (1) relocation info created during code generation and (2) relocation info associated with precompiled function's version. > > Patch from Denis Pravdin <denis.pravdin@intel.com> > BUG=None > LOG=Y > R=svenpanne@chromium.org > > Committed: https://code.google.com/p/v8/source/detail?r=24389 TBR=svenpanne@chromium.org,danno@chromium.org,alph@chromium.org,denis.pravdin@intel.com,weiliang.lin@intel.com BUG=None LOG=N Review URL: https://codereview.chromium.org/624443005 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24394 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yurys@chromium.org authored
The idea behind of this solution is to use the existing "relocation info" instead of consumption the CodeLinePosition events emitted by the V8 compilers. During generation code and relocation info are generated simultaneously. When code generation is done you each code object has associated "relocation info". Relocation information lets V8 to mark interesting places in the generated code: the pointers that might need to be relocated (after garbage collection), correspondences between the machine program counter and source locations for stack walking. This patch: 1. Add more source positions info in reloc info to make it suitable for source level mapping. The amount of data should not be increased dramatically because (1) V8 already marks interesting places in the generated code and (2) V8 does not write redundant information (it writes a pair (pc_offset, pos) only if pos is changed and skips other). I measured it on Octane benchmark - for unoptimized code the number of source positions may achieve 2x ('lin_solve' from NavierStokes benchmark). 2. When a sample happens, CPU profiler finds a code object by pc, then use its reloc info to match the sample to a source line. If a source line is found that hit counter is increased by one for this line. 3. Add a new public V8 API to get the hit source lines by CDT CPU profiler. Note that it's expected a minor patch in Blink to pack the source level info in JSON to be shown. 4.Add a test that checks how the samples are distributed through source lines. It tests two cases: (1) relocation info created during code generation and (2) relocation info associated with precompiled function's version. Patch from Denis Pravdin <denis.pravdin@intel.com> BUG=None LOG=Y R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/616963005 Patch from Denis Pravdin <denis.pravdin@intel.com>. git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24389 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 22 May, 2014 1 commit
-
-
yurys@chromium.org authored
Heap profiler will create a node with name Symbol and type kSymbol. BUG=chromium:376194 LOG=Y R=loislo@chromium.org, yangguo@chromium.org Review URL: https://codereview.chromium.org/290013004 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21433 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 09 May, 2014 1 commit
-
-
ishell@chromium.org authored
1) runtime/references checks temporarily disabled (56 items left) 2) other errors fixed R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/277913002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21222 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 29 Apr, 2014 1 commit
-
-
bmeurer@chromium.org authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/259183002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21035 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 25 Apr, 2014 1 commit
-
-
alph@chromium.org authored
BUG=363976 LOG=Y R=bmeurer@chromium.org, yurys@chromium.org Review URL: https://codereview.chromium.org/259803002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20993 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 19 Apr, 2014 1 commit
-
-
alph@chromium.org authored
LOG=N BUG=363976 R=bmeurer@chromium.org, yurys@chromium.org Review URL: https://codereview.chromium.org/243033002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20866 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 28 Mar, 2014 1 commit
-
-
yurys@chromium.org authored
BUG=v8:3213 LOG=Y R=alph@chromium.org, svenpanne@chromium.org Review URL: https://codereview.chromium.org/197513005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20325 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 17 Mar, 2014 2 commits
-
-
yurys@chromium.org authored
BUG=None TBR=svenpanne@chromium.org LOG=N Review URL: https://codereview.chromium.org/201573002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19956 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yurys@chromium.org authored
OutputStream and ActivityControl are used only by heap profiler so I moved their definition in v8-profiler.h to not clutter v8.h Drive-by: removed OutputStream::GetOutputEncoding which is unused. BUG=None LOG=Y R=alph@chromium.org, svenpanne@chromium.org Review URL: https://codereview.chromium.org/196383015 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19955 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 14 Mar, 2014 1 commit
-
-
yurys@chromium.org authored
StopCpuProfiling is replaced with StopProfiling which returns non-const CpuProfile which allows to call CpuProfile::Delete on it without const_cast. Also replaced StartCpuProfiling with StartProfiling to have symmetric names for start/stop actions. BUG=v8:3213 LOG=Y R=alph@chromium.org, svenpanne@chromium.org Review URL: https://codereview.chromium.org/197873015 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19918 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Feb, 2014 1 commit
-
-
alph@chromium.org authored
LOG=N R=dslomov@chromium.org, yurys@chromium.org Review URL: https://codereview.chromium.org/166383002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19445 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 23 Dec, 2013 1 commit
-
-
yurys@chromium.org authored
BUG=chromium:324769 LOG=N R=hpayer@chromium.org, mstarzinger@chromium.org Review URL: https://codereview.chromium.org/98633009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18404 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Dec, 2013 3 commits
-
-
yurys@chromium.org authored
All methods for accessing collected profiles by index are deprecated. The indexed storage may well be implemented by the embedder should he need it. CpuProfiler's responsibility is just to create CpuProfile object that contains all collected data and whose lifetime can be managed by the embedder. BUG=chromium:327298 LOG=Y R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/117353002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18337 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yurys@chromium.org authored
Object<-->id mapping doesn't depend on a particular snapshot, actually same object may appear in several heap snapshots. The API for converting between id and heap object should be provided by HeapProfiler itself. There is already GetObjectId method which I extended with FindObjectById/ClearObjectIds. As the next step I'm going to deprecate and remove HeapGraphNode::GetHeapValue. BUG=chromium:324769 LOG=N R=alph@chromium.org, hpayer@chromium.org, mstarzinger@chromium.org Review URL: https://codereview.chromium.org/93843004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18334 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
svenpanne@chromium.org authored
R=jochen@chromium.org, mstarzinger@chromium.org, yurys@chromium.org Review URL: https://codereview.chromium.org/99193002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18333 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Dec, 2013 1 commit
-
-
yurys@chromium.org authored
Deleting finished profiles shouldn't interrupt profile recording. BUG=chromium:327298 LOG=N R=alph@chromium.org, jkummerow@chromium.org Review URL: https://codereview.chromium.org/103893003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18302 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 02 Dec, 2013 1 commit
-
-
yurys@chromium.org authored
Deprecated separate methods for starting/stopping allocation tracking in favor of a bool param to Start/StopTrackingHeapObjects. BUG=None LOG=N R=loislo@chromium.org, mstarzinger@chromium.org Review URL: https://codereview.chromium.org/96933003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18197 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 14 Oct, 2013 1 commit
-
-
yurys@chromium.org authored
BUG=277984 R=hpayer@chromium.org Review URL: https://codereview.chromium.org/22852024 Patch from Alexandra Mikhaylova <amikhaylova@google.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17191 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 10 Oct, 2013 1 commit
-
-
yurys@chromium.org authored
CpuProfileNode currently exposes only line number which is not enough for the cases when there is more than one function on the same line. This change exposes column number on CpuProfileNode. BUG=302537 R=jkummerow@chromium.org, loislo@chromium.org Review URL: https://codereview.chromium.org/25541003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17142 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Sep, 2013 1 commit
-
-
dcarney@chromium.org authored
also add a deprecation message for newer gcc versions R=danno@chromium.org BUG= Review URL: https://codereview.chromium.org/25226002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17006 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 10 Sep, 2013 1 commit
-
-
loislo@chromium.org authored
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
-