into the ecx register and to ensure that there is no frame effect
between the first entry to the deferred code and binding its exit.
Review URL: http://codereview.chromium.org/118157

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

external strings so that they are not disposed when running other
tests that rely on only one external string being disposed during its
run.

TBR=kasperl
Review URL: http://codereview.chromium.org/118158

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

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

immediately if holder has this property or saves binary search on holder if
property doesn't belong to holder.  Of course, in the cases when named getter
returns nothing.

That gives ~20% for dom benchmark/Document Object String Get, speeds up overall
dom_perf (not dramatically) and overall score for peacekeeper.  Strange, but DOM
part of peacekeepr runs somewhat slower.
Review URL: http://codereview.chromium.org/118118

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

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


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

Removed duplicates comments in assembler-x64.cc.

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


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

DeferredInlineBinaryOperation::GenerateInlineCode and remove its
definition.  It was only called from one site and was the only
deferred code object that was split that way into fast-case inline and
slow-case stub.

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

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

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

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

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

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

mod so they do not share code with the other binary operations.  They
now preallocate their fixed registers (eax and edx).  There is now no
frame effect between entries to the deferred call to the stub.

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

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

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