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

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


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

GCC version.

BUG=364
TBR=sgjesse@chromium.org
Review URL: http://codereview.chromium.org/118016

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

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

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

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

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

Thanks to Tobias Kaes, an issue with default copy constructor and assignment operator is found and fixed.

BUG=http://code.google.com/p/v8/issues/detail?id=358

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


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

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

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

TBR=erik.corry@gmail.com
Review URL: http://codereview.chromium.org/115917

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

Change the handling of the debug break stack guard. The debug break is no longer ignored when hit inside "system" JavaScript. The reason for this is twofold:

* Running "system" JavaScript with the debug break flag active leads to slow running code while waiting for the break in non "system" JavaScript (one exception to this it is to try to avoid breaks in the clear mirror cache JavaScript code called when leaving the debugger).

* If this happens while processing RegExp running in native code an infinite loop is created as the stack guard handler for RegExp does not move execution forward

Fixed a GC bug in the interrupt handling for RegExp running in native code.

Added test of debug break while in debug message handler callback and debug break while executing a RegExp.
Review URL: http://codereview.chromium.org/115262

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

before performing debugger property lookup make sure the current context is set to the context active before the debugger was entered.

Make the use of the LookupResult GC safe in debugger property lookup.
Review URL: http://codereview.chromium.org/115855

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

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

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

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

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

I suggest that the lack of initialization causes issue 358 to happen. In Profiler::Disengage an empty TickSample is inserted in order to wake up the Profiler thread. Issue reporter claims that crash happens in LogTickEvent function. My guess is that frames_couint receives a wild value.

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


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

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

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

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

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

A very long regexp graph can overflow the stack with recursive calls.

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


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

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

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

to the platform-specific reserved registers.  They are always in use
for their intended purpose, cannot appear in the virtual frame, and
can be freely used without allocation in the code generator.

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

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

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


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2060 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 resolves issue 356 (http://code.google.com/p/v8/issues/detail?id=356) thanks to bitRAKE. Changed benchmark version number from 4 to 5 resulting in updates to base.js, README.txt and revisions.html. 

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

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

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

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

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

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

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

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

whether people are already in it.
Review URL: http://codereview.chromium.org/113834

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

  for scripts.
Review URL: http://codereview.chromium.org/115592

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

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

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

TBR=iposva@chromium.org
Review URL: http://codereview.chromium.org/113829

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

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

called from within a loop or not.  In the past we lost the
information if a call site went megamorphic before a lazily
compiled callee was called for the first time.  Now we track
that correctly (this is an issue that affects richards).
We still don't manage to track the in-loop state through a
constructor call, since constructor calls use LoadICs instead
of CallICs.  This issue affects delta-blue.  So in this patch
we assume that lazy compilations that don't happen through a
CallIC happen from inside a loop.  I have an idea to fix this
but this patch is big enough already.
With our improved tracking of in-loop state I have switched
off the inlining of in-object loads for code that is not in
a loop.  This benefits compile speed.  One issue is that
eagerly compiled code now doesn't get the in-object loads
inlined.  We need to eagerly compile less code to fix this.
Review URL: http://codereview.chromium.org/115744

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

  bits in a page.
Review URL: http://codereview.chromium.org/113819

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

When inspecting a function with a native getter return result of execution of the getter function in the client context. This is useful for debugging DOM elements.
Review URL: http://codereview.chromium.org/113821

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

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

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