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

Support profiler stack sampling in any situation. After this change, almost all profiler ticks (except GC ones) have a stack sample data associated.

Tested under Linux, OS X, and Windows.

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

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

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

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

Please be warned that current gHardy versions have OProfile 0.9.3
which doesn't have JIT API. You need to install OProfile 0.9.4
with a 32-bit version of opagent library. Instructions are on the
internal Wiki page: http://wiki/Main/V8UsingOProfile

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


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

JavaScriptFrameIterator is templatized on the iterator type and renamed to JavaScriptFrameIteratorTemp.
The original JSFI is now a typedef for JavaScriptFrameIteratorTemp<StackFrameIterator>. Because of templatizing, JSFI code is moved to frames-inl.h

StackTraceFrameIterator moved to frames.*

Implemented SafeStackFrameIterator which wraps StackFrameIterator and have the same interface. It performs additional checks of stack addresses prior to delegating to StackFrameIterator. SafeSFI is used in an another specialization of JavaScriptFrameIteratorTemp template to perform safe JS frames iteration on sampler ticks.

I haven't took an advantage of having multiple stack frames in tickprocessor yet.

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

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

TBR=mikhail.naganov
Review URL: http://codereview.chromium.org/28178

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

The testing is a bit tricky because we need to obtain a frame
pointer (EBP on IA-32) from inside of a function. This is especially
interesting in case of a compiled JavaScript function.

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

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

Include all the code in code creation log events. The code object header size is now added to the size Before ticks the last instructions of a JavaScript functions ended up as unaccounted in the profile.Include ticks in the the last created code object in the profile.Show the unaccounted ticks in the profile as a percentage together with the rest. Added an option to ignore unaccounted ticks in the percentage calculation.
Review URL: http://codereview.chromium.org/21410

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

Changed all log messages to be handled through the LogMessageBuilder instead of through fprintf directly to the log file.

Added a flag for the runtime %Log call and fixed its arguments checking. Use of %Log is only for debugging.
Review URL: http://codereview.chromium.org/21406

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

First step in refactoring the logging system to allow the logging messages to have other destinations than an open file.

This change introduces a log message builder which builds the log message in a static string buffer instead of formatting the log message through fprintf. Currently this message can only be written to a file afterwards.

Changed the code related events to use the log message builder.
Review URL: http://codereview.chromium.org/20406

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

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

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

Thus, instead of the following profiler records:
   1.5%    1.5%   LazyCompile: <anonymous>
we'll now have these:
   1.5%    1.5%   LazyCompile: <anonymous> richards.js:309

Basically, I translated two functions from messages.js into C++.
In the next CL I will update messages.js to use added native functions.

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

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

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