created during bootstrapping. Without this change we 
risk having weird flags set on the map for the null
value (among others), which can lead to crashes.
Review URL: http://codereview.chromium.org/552195

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

TBR=kmillikin@chromium.org, 
Review URL: http://codereview.chromium.org/555132

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

I think it currently is defined on all platforms except Android.
Review URL: http://codereview.chromium.org/554101

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

64-bit version now builds on Windows again in both release and debug mode.

The Visual Studio project files have been updated so that all three configurations work (32-bit, 64-bit and 32-bit with ARM simulator). They all convert from Visual Studio 2005 to Visual Studio 2008.

TBR=lrn@chromium.org
Review URL: http://codereview.chromium.org/549174

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

simpler backend for non-toplevel code.

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

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

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

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

when an existing accessor is redefined (a configurable accessor can
potentially be redefined as a non-configurable (i.e., DONT_DELETE)).


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

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

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

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

For now, this is a direct port from ia32, so there is probably still
stuff that can be improved here.
Review URL: http://codereview.chromium.org/555131

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

generator.

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

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

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

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

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

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

objects in the startup heap from a partial snapshot.  This happens
through the partial snapshot cache.  A startup snapshot and a
partial snapshot are created together so that the startup snapshot
contains the partial snapshot cache entries needed.
Review URL: http://codereview.chromium.org/548149

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

on ia32.

1. Operate on the values in edx,eax when possible (all operations
except DIV and MOD).  This saves moving them on entry and when falling
out to the non-smi code.

2. Do not perform ADD and SUB before the smi check of their inputs.
This saves undoing the operation in the case that we fall through to
the non-smi case due to non-smi inputs (probably common?), and we can
avoid emitting the smi check code twice (code size reduction).

3. Don't perform OR twice (once to smi check the inputs and once to
smi check the result).

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

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

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

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

This test have been timing out on ARM hardware from time to time.
Review URL: http://codereview.chromium.org/543206

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

As the start index is already passed it is easy to calculate the "at start" boolean in generated code. Also as direct entry has been implemented this needs to be done in generated code anyway, and therefore might as well be moved to the generated code for RegExp. The "at start" value is now calcualted as a local variable on the native RegExp frame based on the value of the start index argument.

The x64 version have been tested on both Linux and 64-bit Windows Vista.

For ARM I have tested cctest/test-regexp on ARM hardware, but the rest of the tests have only been run on the ARM simulator.
Review URL: http://codereview.chromium.org/554078

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

1. MUL and DIV on SMIs.
2. When calling GenericBinaryOpStub from a virtual frame.
3. When generating code for a loop counter.
Overall performance gain is about 0.6%.
Review URL: http://codereview.chromium.org/555098

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

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

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

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

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

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

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

This reduces chances of improper usage, see http://code.google.com/p/v8/issues/detail?id=586
for more details.

BUG=586

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

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

See Kevin's comments for http://codereview.chromium.org/554062.
Review URL: http://codereview.chromium.org/543193

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

Also fixing some formatting issues.
Review URL: http://codereview.chromium.org/556002

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

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


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

Currently arguments are never passed on registers (due to the way ArgsInRegistersSupported is written) and
if they were, the stub would break in several places because registers are not preserved properly in the
course of execution. This CL makes use of registers more often (than never) and makes sure that registers are
handler properly.
A peformance gain is small (0.2-0.3%) but stable.
This CL was extracted from the one sent out earlier (http://codereview.chromium.org/551093).

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

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

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

See Chromium bug 32637.

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

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

Patch by Erich Ocean and Ryan Dahl.

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

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

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

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

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

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

2.1.0. This means that the next version pushed to trunk will
be the first version in the 2.1.x series. 
Review URL: http://codereview.chromium.org/551139

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

We now test for a smi before calling ToNumber and inline
the smi increment/decrement for ++ and --. There only a small
increase in code size but loops in top-level code are
becoming much faster as a result.

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

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

BUG=589,27967.

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

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

As an afterthought, I realized that I put function objects moves
reporting into a method that deals with only code object moves.  I've
looked up that function objects are allocated in old pointer space and
new space, so I moved logging to the corresponding VM methods.

BUG=553

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

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

The stub for calling RegExp directly now also handles two byte strings.

Support for flat cons strings added for both ascii and two byte.

Some code code simplifications and added a few constants.
Review URL: http://codereview.chromium.org/545151

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

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

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

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

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

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

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