The simple formula "ms = ticks * sampler_interval" doesn't work,
because e.g. on Linux, the actual sampling rate can be 5 times
lower than the one set up in the code. To calculate actual sampling
rate, current time is periodically queried and processed along with
actual sampling ticks count.

Review URL: http://codereview.chromium.org/1539038

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4427 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4422 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This is to make possible enabling usage of the new profiling subsystem
in Chromium without much hassle. The idea is pretty simple: unless the
new profiling API is used, all works as usual, as soon as Chromium
starts to use the new API, it will work too.

Review URL: http://codereview.chromium.org/1635005

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4382 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Also pull out VMState into its own set of source files.

Review URL: http://codereview.chromium.org/1519027

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4361 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

In browser (DevTools) mode, only non-native JS code and callbacks are reported.
Also, added "(garbage collector)" entry which accumulates samples count in GC state.
Trying to display "(compiler)" and "(external)" only brings confusion,
because it ends up in displaying scripts code under "(compiler)" node, and DOM
event handlers under "(external)" node, which looks weird.

Review URL: http://codereview.chromium.org/1523015

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4357 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

If 'shell' is compiled with 'cppprofilesprocessor=on' and run
with '--prof' flag, top-down and bottom-up call trees are printed
on shell exit.

Review URL: http://codereview.chromium.org/1582004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4343 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

 - when logging 'open-tag' / 'close-tag' events, don't depend on
   FLAG_log (as it may be not enabled, e.g. in Chromium);

 - PauseProfiler / ResumeProfiler were supposing that they
   use 'is_logging_' var exclusively, thus preventing any
   other logging that may be turned on for diagnostic purposes.

Review URL: http://codereview.chromium.org/661246

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3986 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

It doesn't mean I'm participating in some fixit, just spotted some
code which doesn't have usages and decided to remove it.

Review URL: http://codereview.chromium.org/646007

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3896 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This change allows to associate integer tags with blocks of profiler
log events, and repeat calls to 'ResumeProfiler' / 'PauseProfiler' in
order to establsh nested (not necessary properly nested) blocks. By
supporting this, we will be able to match WebInspector's CPU profiler
abilities in DevTools.

I also refactored some testing code.

Review URL: http://codereview.chromium.org/619004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3889 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

After this fix, profiles of non-snapshotted VMs are now equivalent to
profiles of snapshotted VMs (having that --log-snapshot-positions is used,
and mksnapshot's log is given to the tick processor script.)

BUG=597

Review URL: http://codereview.chromium.org/574005

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3802 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

The problem appeared due to a fact that stubs doesn't create a stack
frame, reusing the stack frame of the caller function. When building
stack traces, the current function is retrieved from PC, and its
callees are retrieved by traversing the stack backwards. Thus, for
stubs, the stub itself was discovered via PC, and then stub's caller's
caller was retrieved from stack.

To fix this problem, a pointer to JSFunction object is now captured
from the topmost stack frame, and is saved into stack trace log
record. Then a simple heuristics is applied whether a referred
function should be added to decoded stack, or not, to avoid reporting
the same function twice (from PC and from the pointer.)

BUG=553
TEST=added to mjsunit/tools/tickprocessor

Review URL: http://codereview.chromium.org/546089

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3673 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

As this is only needed for internal profiling (not for DevTools),
the following approach had been chosen:

 - during snapshot creation, positions of serialized objects inside
   a snapshot are logged;

 - then during V8 initialization, positions of deserealized objects
   are logged;

 - those positions are used for retrieving code objects names from
   snapshot creation log, which needs to be supplied to tick processor
   script.

Positions logging is controlled with the new flag: --log_snapshot_positions.
This flag is turned off by default, and this adds no startup penalty.

To plug this fix to Golem, the following actions are needed:

 - logs created using 'mksnapshot' need to be stored along with VM images;

 - tick processor script needs to be run with '--snapshot-log=...' cmdline
   argument.

BUG=571

Review URL: http://codereview.chromium.org/551062

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3635 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Logging getters and setters from DOM API is extremely useful for web
developers as setting (and getting!) several properties can cause
page relayouts which take significant time.

Review URL: http://codereview.chromium.org/434074

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3363 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Callback entry address is stored in VMState and is later retrieved by
profiler stack sampler. This makes possible relating API entry to JS
stack, and this is simpler than trying to unwind native stack.

Review URL: http://codereview.chromium.org/437004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3344 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Now they are logging during "LogCompiledFunctions" cycle. API functions
are detected by examining SFI's "function_data" field.

Review URL: http://codereview.chromium.org/414036

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3343 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This is needed to show calls to DOM in CPU profiles. I can think
of a better approach like adding specific functions into V8 API
for explicitly providing callback names and modifying bindings codegen
appropriately. My plan is as follows:
 - submit this CL;
 - implement anything I need to process log data and display DOM
   calls in profiles;
 - think again about adding specific functions and modifying bindings
   codegen.

BUG=http://code.google.com/p/chromium/issues/detail?id=27613

Review URL: http://codereview.chromium.org/402100

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3340 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

a sensible output.
Review URL: http://codereview.chromium.org/385039

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3281 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

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

Also, perform some refactoring to reuse common code between constructor and retainer profiles.

Review URL: http://codereview.chromium.org/209028

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2936 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

I'm planning to use it in DevTools heap profiler. It is a common scenario in debugging memory leaks to enforce GC, then perform an operation, then enforce GC again to check for non-collected (that is, leaked) objects. Using the existing GC extension isn't possible because it doesn't exposed in the normal operation mode of Chromium.

Review URL: http://codereview.chromium.org/159787

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2619 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 changed time reporting to system time to be able to get synchronized with other memory (e.g. DOM) size status.

Review URL: http://codereview.chromium.org/155764

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2509 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/125141

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2263 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

(Android does this).  Fix logging for executable mappings that have no
file associated.  Be more consistent with use of uintptr_t.
Review URL: http://codereview.chromium.org/125183

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2187 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Code addresses are now written as an offset from the previous address for ticks, code move and delete events. Employed backreference and RLE compression for code move and delete events. This gives additional 30% log size reduction for benchmarks run w/o snapshot.

Overall compression results (compared with the revision of V8 having no compression):
 - V8: 70% size reduction for benchmarks run w/o snapshot (for reference, gzip gives 87%)
 - Chromium: 65% size reduction for public html version of benchmarks (v4) (for reference, gzip gives 90%)

The one obvious opportunity for improving compression results in Chromium is to compress URLs of scripts.

Review URL: http://codereview.chromium.org/125114


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2162 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Two techniques are involved:
 - compress repeated line ends (common stack beginnings) by using back references;
 - do RLE compression of repeated tick events.

This gives only 5% size reduction on benchmarks run, but this is because tick events are only comprise 10% of file size. Under Chromium winnings are bigger because long repeated samples of idleness are now compressed into a single line.

Tickprocessor will be updated in the next patch.

Review URL: http://codereview.chromium.org/123012


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2147 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

My assumption that log initialization happens somewhere near the stack's bottom is true for V8's sample shell but isn't true for Chromium, causing many otherwise valid stack addresses to be thrown out. The solution proposed is to save stack pointer value for the outermost JS function in ThreadLocalTop similar to c_entry_fp.

Implemented only for IA-32. Currently I'm not dealing with profiling on ARM and x86-64 anyway.

Review URL: http://codereview.chromium.org/112082


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2086 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Two simple profiler changes: 1) log sampling rate, 2) check current state before pausing & resuming.

Review URL: http://codereview.chromium.org/113961


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2073 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

When profiler's memory buffer is filled up, profiling is stopped and it is ensured that the last record in the buffer is "profiler,\"pause\"" thus making the end of profiling session explicit. Otherwise DevTools Profiler would need to guess whether the current profiling session has been stopped.

Tested with Chromium.

Review URL: http://codereview.chromium.org/115859


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2072 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This issue was raised by Brett Wilson while reviewing my changelist for readability. Craig Silverstein (one of C++ SG maintainers) confirmed that we should declare one namespace per line. Our way of namespaces closing seems not violating style guides (there is no clear agreement on it), so I left it intact.

Review URL: http://codereview.chromium.org/115756


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2038 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

All changes from http://codereview.chromium.org/115024, except splitting namespace declarations in two lines (will be done separately for all source files).

Review URL: http://codereview.chromium.org/113763


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2037 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This is intended to be used with Chromium. When in resource-saving mode, profiler doesn't consume any resources (sampler and logging is off) until resumed. Then again, when profiler is paused, sampling and logging are turned off.

Tested under Linux and Windows. Also have done preliminary testing with Chromium.

Review URL: http://codereview.chromium.org/113762


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2036 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

The goal is to make possible having --prof flag always enabled in Chromium.  Currently we can't do this because --prof causes compiler and gc to log code creations / moves / deletes which aren't needed until we start profiling.  With LogCompiledFunctions it will be possible not to log anything until we start profiling.  When started, the current map of compiled functions will be logged and compiler / gc logging will be enabled to update current state.  When profling is stopped, logging will be turned off again.

Funny that testing code is actually much longer and complex than function code.

Review URL: http://codereview.chromium.org/112036

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2009 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/114010


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1893 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

Review URL: http://codereview.chromium.org/67221

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1728 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

on a real web application loaded in the test shell.

Also implemented output of JSON-encoded call stacks for profiler
prototype.

Review URL: http://codereview.chromium.org/56064

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1646 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

 - String traversal test data (now in a zone)
 - Debug message thread (now joined on exit)
 - Threading test threads (now joined on exit)
 - Changed message tests framework to cope with valgrind
Also, fixed a bug where we'd try to delete stack-allocated objects
when tearing down v8.  Good times.


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1622 ce2b1a6d-e550-0410-aec6-3dcde31c8c00