-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
