Turned on with '--log-producers' flag, also needs '--noinline-new' (this is temporarily), '--log-code', '--log-gc'. Not all allocations are traced (I'm investigating.)
Stacks are stored using weak handles. Thus, when an object is collected, its allocation stack is deleted.
Review URL: http://codereview.chromium.org/267077
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3069 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
fast code generator is optimized for compilation time and code size.
Currently it is only implemented on IA32. It is potentially triggered
for any code in the global scope (including code eval'd in the global
scope). It performs a syntactic check and chooses to compile in fast
mode if the AST contains only supported constructs and matches some
other constraints.
Initially supported constructs are
* ExpressionStatement,
* ReturnStatement,
* VariableProxy (variable references) to parameters and
stack-allocated locals,
* Assignment with lhs a parameter or stack-allocated local, and
* Literal
This allows compilation of literals at the top level and not much
else.
All intermediate values are allocated to temporaries and the stack is
used for all temporaries. The extra memory traffic is a known issue.
The code generated for 'true' is:
0 push ebp
1 mov ebp,esp
3 push esi
4 push edi
5 push 0xf5cca135 ;; object: 0xf5cca135 <undefined>
10 cmp esp,[0x8277efc]
16 jnc 27 (0xf5cbbb1b)
22 call 0xf5cac960 ;; code: STUB, StackCheck, minor: 0
27 push 0xf5cca161 ;; object: 0xf5cca161 <true>
32 mov eax,[esp]
35 mov [ebp+0xf4],eax
38 pop eax
39 mov eax,[ebp+0xf4]
42 mov esp,ebp ;; js return
44 pop ebp
45 ret 0x4
48 mov eax,0xf5cca135 ;; object: 0xf5cca135 <undefined>
53 mov esp,ebp ;; js return
55 pop ebp
56 ret 0x4
Review URL: http://codereview.chromium.org/273050
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3067 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The profile is taken together with constructors profile. In theory, it
should represent a complete heap graph. However, this takes a lot of memory,
so it is reduced to a more compact, but still useful form. Namely:
- objects are aggregated by their constructors, except for Array and Object
instances, that are too hetereogeneous;
- for Arrays and Objects, initially every instance is concerned, but then
they are grouped together based on their retainer graph paths similarity (e.g.
if two objects has the same retainer, they are considered equal);
Review URL: http://codereview.chromium.org/200132
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2903 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The SCons build now has the options profilingsupport and debuggersupport for controlling the setting of the defines ENABLE_LOGGIGN_AND_PROFILING and ENABLE_DEBUGGER_SUPPORT. By default both are set to true.
The changes to the XCode project have not been tested.
Review URL: http://codereview.chromium.org/195061
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2875 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-fstrict-aliasing is enabled by mainline gcc at -O2 and higher, but in Apple
gcc, it must be enabled explicitly. This results in a 1.5% improvement in V8
benchmark scores.
This also removes the -fno-exceptions and -fno-rtti settings from v8.gyp for
the Mac, and removes -fno-rtti from v8.gyp for Linux, because these settings
have become part of Chromium's common.gypi, included here, as of r23304 at the
latest. The settings in v8.gyp have become redundant.
Review URL: http://codereview.chromium.org/174154
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2734 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
system can't currently process stacks produced by gcc -fomit-frame-pointer
properly. The drawback outweighs the 2% performance improvement. Once
the crash reporting system is able to handle this optimization, it should be
revisited.
Review URL: http://codereview.chromium.org/173123
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2733 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
These files will make it possible to start working with the 64-bit version on Windows.
The GUID's of the x64 project files are the same as their ia32 counterparts, but that does not matter as they will never be used in the same solution.
Added a temporary #error when building 64-bit version on Windows.
Review URL: http://codereview.chromium.org/171111
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2711 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
MSVS names '.map' file using only module's name, so both 'a.exe' and 'a.dll' will have 'a.map' file. To distinguish an originating module, we're now checking for image base which is always 00400000 for .exe files, and not 00400000 for .dlls.
Verified that windows-tick-processor can now process logs from Chromium using .map file generated for 'chrome.dll', an that it still works for V8's 'shell.exe'.
Review URL: http://codereview.chromium.org/172044
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2699 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
generated in one-pass from the source AST, code is generated from the
CFG. Enabled by the flag --multipass and disabled by default.
Rudimentary and currently only supports literal expressions and return
statements. There are some other known limitations (e.g., missing
support for tracing).
Review URL: http://codereview.chromium.org/159695
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2596 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
It is activated with '--log-gc' flag.
JS object size is calculated as its size + size of 'properties' and 'elements' arrays, if they are non-empty. This doesn't take maps, strings, heap numbers, and other shared objects into account.
As Soeren suggested, I've moved ZoneSplayTree from jsregexp to zone, and removed now empty jsregexp-inl header file.
Review URL: http://codereview.chromium.org/159504
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2570 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Also, add user time into heap sample begin events to make '--log-gc' flag alone sufficient for producing heap logs (previously, samples times were extracted from scavenge events which are only logged with '--log' flag).
Review URL: http://codereview.chromium.org/149611
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2461 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
'nm' is now called with an option to report function code sizes. Static code entries are restricted to the sizes reported, and the remaining unnamed code is attributed to a library as a whole. This makes reports more accurate, as some functions are tiny, but has chunks of unnamed code behind them.
This change doesn't affect reporting on Windows, as in .map files function code sizes aren't specified.
Review URL: http://codereview.chromium.org/149513
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2455 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Without an explicit check if a function belongs to shared library address space, "finishing" a library symbols processing with 'addPrevEntry(libEnd);' can cause emission of code entries which cover almost the entire address space, shadowing other code.
Review URL: http://codereview.chromium.org/131033
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2221 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The main problem was due to the following: after Erik had fixed the logger to report library addresses, tickprocessor started to add to the code map entries that covered almost entire memory. This happened because tickprocessor contains a heuristic to bias addresses of functions from dynamic libraries:
if (funcInfo.start < libStart && funcInfo.start < libEnd - libStart) {
funcInfo.start += libStart;
}
And, as tickprocessor tried to process all symbols from the library, including data entries, which can be outside reported library addresses range, the second condition failed, and funcInfo.start remained unbiased.
Review URL: http://codereview.chromium.org/125192
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2194 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
To profile running the JavaScript file test.js using the V8 release mode shell (assuming it is build passing prof=oprofile to the SCons build). The following commands can be used:
$ tools/oprofile/start
$ tools/oprofile/run test.js
$ tools/oprofile/report | less
$ tools/oprofile/annotate | less
$ tools/oprofile/shutdown
Here is a summary of the commands.
For all the commands taking an executable the executable is expected to be a binary using V8. If no executable is specified the release mode V8 shell is assumed.
By default the --session-dir=/tmp/oprofv8 is passed to all oprofile commands. This walue can be changed by setting environment variable OPROFILE_SESSION_DIR.
When using the defaulf executable (V8 shell in release mode) it is assumed to be located in ../.. relative from the oprofile utility scripts. This default location can be overridden using the V8_SHELL_DIR environment variable.
start
-----
Start the oprofiling daemon.
run [executable] [parameters]
-----------------------------
Profile a V8 executable. Running this will reset oprofile samples, run the command and do an oprofile dump to flush samples and write ELF binaries for the generated code. The parameters are passed to the executable together with the --oprofile option.
report [executable] [parameters]
--------------------------------
Print the report for a profile run. The parameters are passed to opreport. E.g report --callgraph.
annotate [executable] [parameters]
----------------------------------
Print annotated assembly for a profile run. The parameters are passed to opannotate. E.g annotate -threshold 1.
reset
-----
Reset oprofile samples.
dump
----
Flush oprofile samples and write ELF binaries for the generated code.
shutdown
--------
Shutdown oprofile daemon.
Added a warning which is printed if option --oprofile is passed to a V8 which has not been compiled with oprofile support.
Review URL: http://codereview.chromium.org/125181
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2186 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is a trivial per-row compression:
- short aliases are introduced for events and code creation tags;
- in tick events, offsets are used instead of absolute addresses;
- removed 'code-allocation' event, as it seems not used.
The first two options are depend on the new flag: 'compress-log', which is off by default.
On benchmarks run w/o snapshot, this gives 45% log size reduction.
Review URL: http://codereview.chromium.org/119304
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2122 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Change stack alignment on linux to 16 bytes to keep gcc 4.4 happy.
This fixes the mksnapshot segfault without requiring -fno-tree-vectorize
which just avoided the problem by not generating code with movdqa.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2107 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The goal of this change is to allow longer profiling sessions and preserve memory when profiler isn't started. The buffer starts with 64K and grows until it reaches the upper limit, which is currently set to 50MB --- according to my evaluations, this is enough for at least 20 minutes of GMail profiling. As we're planning to introduce compression for the profiler log, this time boundary will be significantly increased soon.
To make possible unit testing of the new component, I've factored out Logger's utility classes into a separate source file: log-utils.h/cc. Log and LogMessageBuilder are moved there from log.cc without any semantical changes.
Review URL: http://codereview.chromium.org/115814
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2067 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
encoding the values in one word and by using an indirection table for
handles.
This reduces compilation time by roughly 10% and we should be able to make the slow case equality checking of frame elements faster as well.
Review URL: http://codereview.chromium.org/115347
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1949 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This will enable reading profiler log in Chrome. The current implementation of memory buffer is trivial (fixed size buffer, no memory recycling) but enough to start end-to-end DevTools Profiler implementation. Later it will be enhanced.
Review URL: http://codereview.chromium.org/108011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1870 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- TARGET, the architecture we will generate code for.
This is brought it from the build system.
- HOST, the architecture our C++ compiler is building for.
This is detected automatically based on compiler defines.
This adds macros for 32 or 64 bit, and cleans up some
include conditionals, etc.
Review URL: http://codereview.chromium.org/99355
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1864 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The current version is now held in src/version.cc in a number of defines which needs to be modified when changing version.
The following defines make up the version information:
MAJOR_VERSION
MINOR_VERSION
BUILD_NUMBER
PATCH_LEVEL
CANDIDATE_VERSION
The first four are numbers and the fifth is a boolean. Besides these five the define
SONAME
can be used to set a specific soname when building the a shared library (see below). This will most likely be used on stable branches where binary compatibility is ensured between different versions. This define is a string.
This version information is now read by the SCons build to support setting the soname for a Linux shared library. This requires passing the option soname=on to the SCons build.
When soname=on is specified the soname for the shared library can be set in two different ways. Either it will be the full versioned library name (e.g. libv8-1.2.2.so) or a specific soname defined in src/version.cc. Whenever a shared library is build with an soname the filename of the library will hold the full version name (e.g. libv8-1.2.2.so).
I did not update the xcode project with the new files.
BUG=151
Review URL: http://codereview.chromium.org/100104
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1826 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is an effort to reuse profiler data processing code both in
TickProcessor and Dev Tools Profiler. The old Python implementation
will be removed.
The new TickProcessor works almost identical to the previous one.
However, it has some differences:
1. Not very useful "Call profile" section is replaced with a new
WebKit-like "Bottom up (heavy) profile" which shows the most
expensive functions together with their callers. I used it
personally in order to find and remove bottlenecks in the
tickprocessor script itself, and found it quite helpful.
2. Code entries with duplicate names (they occur for RegExes, stubs
and sometimes for anonymous Function objects) are now distinguished
by adding an occurence number inside curly brackets.
3. (Address -> code entry) mapping is more precise in boundary cases.
4. Windows version no more requires specifying .map file location.
5. Works faster.
Review URL: http://codereview.chromium.org/99054
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1802 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Gyp is used to generate project files used to build chromium. Moving
the v8.gyp file to the v8 repository makes it easier to have V8 and
the v8.gyp file synchronized (so a DEPS update in chromium gets the
right v8.gyp file associated with that revision of V8).
Review URL http://codereview.chromium.org/100035
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1795 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
