- 19 Feb, 2019 1 commit
-
-
Vadim Gorbachev (bmsdave) authored
There are now less that 400 days until the end of life of Python 2(aka _legacy_ Python) https://pythonclock.org/ . The code compatibility check for python2 and python3 used the following tools: futurize, flake8 You can see the reports here: https://travis-ci.com/bmsdave/v8/builds This CL was uploaded by git cl split. Bug: v8:8594 Change-Id: I661c52a70527e8ddde841fee6d4dcba282b4a938 Reviewed-on: https://chromium-review.googlesource.com/c/1470123 Commit-Queue: Sergiy Belozorov <sergiyb@chromium.org> Reviewed-by: Sergiy Belozorov <sergiyb@chromium.org> Cr-Commit-Position: refs/heads/master@{#59675}
-
- 06 Apr, 2016 1 commit
-
-
ssanfilippo authored
An overzealous removal in https://crrev.com/9e39a9fff1c2966a3f650a4c31dbbe533886d614 caused the disassembly not to be annotated with ticks, even when requested. LOG=N Review URL: https://codereview.chromium.org/1861323002 Cr-Commit-Position: refs/heads/master@{#35298}
-
- 05 Apr, 2016 1 commit
-
-
ssanfilippo authored
LOG=N Review URL: https://codereview.chromium.org/1796863002 Cr-Commit-Position: refs/heads/master@{#35268}
-
- 26 Feb, 2016 1 commit
-
-
rmcilroy authored
Adds support for cpu profiler logging to the interpreter. Modifies the the API to be passed AbstractCode objects instead of Code objects, and adds extra functions to AbstractCode which is required by log.cc and cpu-profiler.cc. The main change in sampler.cc is to determine if a stack frame is an interpreter stack frame, and if so, use the bytecode address as the pc for that frame. This allows sampling of bytecode functions. This requires adding support to SafeStackIterator to determine if a frame is interpreted, which we do by checking the PC against pre-stored addresses for the start and end of interpreter entry builtins. Also removes CodeDeleteEvents which are dead code and haven't been reported for some time. Still to do is tracking source positions which will be done in a followup CL. BUG=v8:4766 LOG=N Review URL: https://codereview.chromium.org/1728593002 Cr-Commit-Position: refs/heads/master@{#34321}
-
- 22 Jan, 2016 2 commits
-
-
mtrofin authored
This simplifies correlating offsets with the output from --print-opt-code, which outputs offsets in decimal. We keep the hex output since branch instructions in the perf dump use hex labels. We just include the decimal offset along with the hex offset. BUG= Review URL: https://codereview.chromium.org/1612403002 Cr-Commit-Position: refs/heads/master@{#33455}
-
mtrofin authored
Show tick count, besides the percentage spent on an instruction. Aids perf investigations where we deal with stalls, for example. Percentage-wise, the execution appears distributed similarly, but the regression becomes more apparent in the tick counts. Review URL: https://codereview.chromium.org/1607323003 Cr-Commit-Position: refs/heads/master@{#33452}
-
- 26 Nov, 2015 1 commit
-
-
jie.pan authored
Newer perf.data contains both MMAP and MMAP2 record type, but MMAP2 record type is not supported in previous ll_prof, MMAP2 record information will be lost. BUG=v8:4569 LOG=n Review URL: https://codereview.chromium.org/1469153004 Cr-Commit-Position: refs/heads/master@{#32319}
-
- 16 Mar, 2015 1 commit
-
-
jacob.bramley authored
BUG= Review URL: https://codereview.chromium.org/1007613005 Cr-Commit-Position: refs/heads/master@{#27213}
-
- 24 Jun, 2014 1 commit
-
-
baptiste.afsa@arm.com authored
R=ulan@chromium.org Review URL: https://codereview.chromium.org/353643003 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21965 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 07 Dec, 2012 1 commit
-
-
jkummerow@chromium.org authored
Review URL: https://codereview.chromium.org/11444031 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13168 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 06 Sep, 2012 1 commit
-
-
ulan@chromium.org authored
R=mstarzinger@chromium.org Review URL: https://chromiumcodereview.appspot.com/10908122 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12469 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 13 Jan, 2012 1 commit
-
-
yangguo@chromium.org authored
Review URL: http://codereview.chromium.org/9205002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10398 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 09 Nov, 2011 1 commit
-
-
vitalyr@chromium.org authored
BUG= TEST= Review URL: http://codereview.chromium.org/8509006 Patch from Gergely Kis <gergely@homejinni.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9944 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 19 Sep, 2011 1 commit
-
-
vegorov@chromium.org authored
Review URL: http://codereview.chromium.org/7945009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9328 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 29 Jun, 2011 1 commit
-
-
vitalyr@chromium.org authored
R=fschneider@chromium.org Review URL: http://codereview.chromium.org/7282011 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8473 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 May, 2011 1 commit
-
-
vitalyr@chromium.org authored
Review URL: http://codereview.chromium.org/7039040 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7940 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 29 Apr, 2011 1 commit
-
-
vitalyr@chromium.org authored
Switched to using binary low-level log instead of the textual log used by the ticks processor. The binary log contains code-related events, code object names, and their bodies. When writing to the log we ask glibc to use a larger buffer. To avoid complex processing of the snapshot log (which is still textual) the serializer emits final snapshot position to code name mappings that can be quickly be read without replaying the snapshot log. (This might be useful for the ticks processor.) Review URL: http://codereview.chromium.org/6904127 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7729 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 22 Feb, 2011 2 commits
-
-
mikhail.naganov@gmail.com authored
The main issue was due to multiple recompilations of functions. Now code objects are grouped by function using SFI object address. JSFunction objects are no longer tracked, instead we track SFI object moves. To pick a correct code version, we now sample return addresses instead of JSFunction addresses. tools/{linux|mac|windows}-tickprocessor scripts differentiate between code optimization states for the same function (using * and ~ prefixes introduced earlier). DevTools CPU profiler treats all variants of function code as a single function. ll_prof treats each optimized variant as a separate entry, because it can disassemble each one of them. tickprocessor.py not updated -- it is deprecated and will be removed. BUG=v8/1087,b/3178160 TEST=all existing tests pass, including Chromium layout tests Review URL: http://codereview.chromium.org/6551011 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6902 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
vitalyr@chromium.org authored
Analyses full minidump (.dmp) files. Shows the processor state at the point of exception including the stack of the active thread and the referenced objects in the V8 heap. Code objects are disassembled and the addresses linked from the stack (pushed return addresses) are marked with "=>". Review URL: http://codereview.chromium.org/6312058 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6896 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 07 Dec, 2010 2 commits
-
-
kasperl@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5921 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
kasperl@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5920 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 28 Oct, 2010 1 commit
-
-
vitalyr@chromium.org authored
Review URL: http://codereview.chromium.org/4097011 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5727 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 19 Oct, 2010 1 commit
-
-
vitalyr@chromium.org authored
Since 2.6.31 perf_events interface has been available in the kernel. There's a nice tool called "perf" (linux-2.6/tools/perf) that uses this interface and provides capabilities similar to oprofile. The simplest form of its usage is just dumping the raw log (trace) of events generated by the kernel. In this patch I'm adding a script (tools/ll_prof.py) to build profiles based on perf trace and our code log. All the heavy-lifting is done by perf. Compared to oprofile agent this approach does not require recompilation and supports code moving garbage collections. Expected usage is documented in the ll_prof's help. Basically one should run V8 under perf passing --ll-prof flag and then the produced logs can be analyzed by tools/ll_prof.py. The new --ll-prof flag enables logging of generated code object locations and names (like --log-code), and also of their bodies, which can be later disassembled and annotated by the script. Review URL: http://codereview.chromium.org/3831002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5663 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-