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

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

TBR=whesse@chromium.org,lrn@chromium.org
Review URL: http://codereview.chromium.org/118310

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

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


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

deferred code snippets are highly stylized.  They always make a call
to a stub or the runtime and then return.  This change takes advantage
of that.

Creating a deferred code object now captures a snapshot of the
registers in the virtual frame.  The registers are automatically saved
on entry to the deferred code and restored on exit.

The clients of deferred code must ensure that there is no change to
the registers in the virtual frame (eg, by allocating which can cause
spilling) or to the stack pointer.  That is currently the case.

As a separate change, I will add either code to verify this constraint
or else code to forbid any frame effect.

The deferred code itself does not use the virtual frame or register
allocator (or even the code generator).  It is raw macro assembler
code.
Review URL: http://codereview.chromium.org/118226

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

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

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

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

submitted in revisions 2093, 2094, 2099, and 2106.
There's no evidence that supports that these changes
should be the cause of the unexplained performance
regressions on the intl2 and DHTML page cyclers. 


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

2106 to try to isolate a performance regression on the
page cyclers.

I'll roll the changes back in if this doesn't fix the
regression.

TBR=antonm@chromium.org
Review URL: http://codereview.chromium.org/118302

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

Change stack alignment on linux to 16 bytes to keep gcc 4.4 happy. 
This fixes the mksnapshot segfault without requiring -fno-tree-vectorize
which just avoided the problem by not generating code with movdqa.


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

The problem was I incorrectly treated NULL result as failure to fetch
a property with a getter.  However, if getter returns zero, it is
manifested as NULL pointer (see added test case).

Good news: that gives another boost as before this CL if getter returned
0, I did another slow lookup.

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

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

indentation.

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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