sure to suspend the thread (if necessary) on mac/win32 before 
reading the VM state.

Avoid dealing with signals delivered to non-VM threads on 
linux no matter if we're profiling or not.
Review URL: http://codereview.chromium.org/3845006

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

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

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

avoid getting a profiling sample while not holding the locker,
because we will not get a stack sample in that case.
Review URL: http://codereview.chromium.org/668063

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

in the test-log/ProfMultipleThreads.
Review URL: http://codereview.chromium.org/669058

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

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

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

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

Set warning level to /W3 and change implicit conversions from size_t
to int. Most "fixes" are simply manifesting the implicit casts or using
a special strlen replacement that returns int.

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


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

- don't engage the processing thread of CPU profiling until the first time profiling is resumed, this saves us a thread allocation for the majority of users;
- don't log shared libraries addresses: this is useless for JS-only profiling, and also consumes time on startup.

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

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

When starting JS profiling under Chromium, a map from function addresses to function names is created. During it, for sourceful scripts, an attempt to access script source is made. This can cause a crash, if a source is an external string, which already has been disposed. We had a similar problem in the past with DebugGetLoadedScripts.

BUG=http://crbug.com/23768
TEST=test-log/Issue23768

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

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

* Rename some instance variables and accessors to fit code style.
* Don't overwrite existing thread ID.
Review URL: http://codereview.chromium.org/251014

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

I have several Chromium's core files having SIGPROF signal handler called in the context of an arbitrary thread, causing a crash. This change introduces checking of current thread in the signal handler.

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

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

BUG=none
TEST=none

TBR=ager

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

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

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

I found two causes of flakinness:
 - SIGPROF signal isn't delivered to a process;
 - Profiler thread (the one that retrieves tick events from
   the queue and writes to log) doesn't get a CPU;
Both are fixed.

The script from bug description with run count increased to 200 runs without any test failures.

OS X and Windows are unaffected because they don't use signals mechanism.

BUG=http://code.google.com/p/v8/issues/detail?id=410
TEST=see bug description

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


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

Also, add a small delay to be sure that all ticks are logged prior to leaving CheckThatProfilerWorks function.

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


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

While testing ProfLazyMode stability I encountered a situation when the cycle supposed to run for 200 ms started to run "infinitely" because delta between two int64_t values became negative.

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


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

Prior to this change debug version of the test crashed 2 of 1000 times. After the change no crashes (out of 1000 runs) occured.

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


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

This allows us to optimized the EnsureInitialized() function
so it doesn't require a function call when we're running

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

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

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


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

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


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

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


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

If was failing because with snapshot the range between minimum and maximum addresses of heap objects is very large (close to 0xf0000000). To fix this I rewrote handling of address maps in the test.

Submitting with TBR because of late time. I think, we'll need to revisit this change tomorrow.

TBR=sgjesse@chromium.org

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


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

Sorry for not testing these prior to committing.

TBR=sgjesse@chromium.org

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


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

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