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
idle notifications after the one that causes the mark-compact
collection unless four or more garbage collections (scavenges) have
occurred.
The embedder should stop sending idle notifications once V8 returns
true from the IdleNotification call. This change is being defensive so
it will not hurt as badly if embedders continue to send idle
notifications.
Review URL: http://codereview.chromium.org/5726005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5981 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Allow build-time customization of the max semispace size. Building a
version of V8 with snapshots and with a non-default max semi-space
size is much easier when you can set the max semispace size in the
build environment.
Review URL: http://codereview.chromium.org/4937001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5823 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Currently weak handles retain an object for another GC round (oftem times,
major GC round.) Instrumenting Chromium shows that navigation leaves
many global objects which are only collected in next go. Let's
attempt to collect more garbage when approacing OOM condition.
This is a better version of rolled out r5455: now it's correctly
rebuilds object groups between additional GCs.
Review URL: http://codereview.chromium.org/4295004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5761 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
An attempt to retrieve security context for a function may fail if the
destination heap space is in an incomplete state. To fix this, we only
record unknown functions discovered at GC object moves, and then
register them after GC completes.
BUG=crbug/59627
Review URL: http://codereview.chromium.org/3763012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5667 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
The object's space in Page starts after Page header and is aligned to kMapAlignment which is 32 bytes on 32-bit and 8 bytes on 64-bit.
In case of 64-bit target, the current page header size is exactly 32 bytes so we get the code magically aligned at 32 bytes but it is better to have a separate CODE_POINTER_ALIGN macro to make sure the object space in Page is aligned properly for both maps and code.
There could be a small waste of bytes sometimes (since both Page header and Code header sizes are aligned separately) but it seems the optimal one would involve cross-dependencies between .h files and not clear if it's worth it.
This is a back-port from Isolates branch.
Review URL: http://codereview.chromium.org/3461021
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5526 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The cause for missing functions is that some of them are created
from compiled code (see FastNewClosureStub), and thus not get
registered in profiler's code map.
My solution is to hook on GC visitor to provide JS functions
addresses to profiler, only if it is enabled.
BUG=858
TEST=
Review URL: http://codereview.chromium.org/3417019
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5523 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The number of inobject properties used to be derived from the number
of this property assignments in the constructor (and increased by 2 to
allow for properties added later). This very often leads to wasted inobject
slots.
This patch reclaims some of the unused inobject space by the following method:
- for each constructor function the first several objects are allocated using the initial
("generous) instance size estimation (this is called 'tracking phase').
- during the tracking phase map transitions are tracked and actual property counts are collected.
- at the end of the tracking phase instance sizes in the maps are decreased if necessary
(starting with the function's initial map and traversing the transition tree).
- all further allocation use more realistic instance size estimation.
Shrinking generously allocated objects without costly heap traversal is made possible
by initializing their inobject properties with one_pointer_filler_map (instead of undefined).
The initial slack for the generous allocation is increased from 2 to 6 which really helps some tests.
Review URL: http://codereview.chromium.org/3329019
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5510 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Currently weak handles retain an object for another GC round (oftem times,
major GC round.) Instrumenting Chromium shows that navigation leaves
many global objects which are only collected in next go. Let's
attempt to collect more garbage when approacing OOM condition.
Review URL: http://codereview.chromium.org/3327021
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5455 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
That could improve chances for commit success as currently,
if we moved free pages out of order, we cannot shrink spaces.
However, when we experience problems commiting from space back, we should
use most of resources at our disposal.
Also get rid of currently unused parameter to DeallocateFunction.
Review URL: http://codereview.chromium.org/3260001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5372 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
the code object's instructions.
This allows us to find a code object using just the pc. This approach
uses a cache (PcToCodeCache) to make sure we don't continuously have
to iterate heap pages.
This change eliminates the need for cooking and uncooking of stack frames.
Review URL: http://codereview.chromium.org/3226014
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5369 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
