This optimization turns out to have a negative effect on i5 processors
throughout the board. This needs further investigation to figure out
the underlying reason but will be rolled out for now.

R=danno@chromium.org

Review URL: https://codereview.chromium.org/12388016

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

R=verwaest@chromium.org
BUG=

Review URL: https://chromiumcodereview.appspot.com/12388015

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

R=ulan@chromium.org
BUG=

Review URL: https://chromiumcodereview.appspot.com/12315130

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

Review URL: https://chromiumcodereview.appspot.com/12226090

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

- Later the different parts will become individual code objects that tailcall into one another.
- The mapcheck/symbol check still needs to be separated from the overall prototype-chain check so that the ICs can reuse the handlers.

Review URL: https://chromiumcodereview.appspot.com/12209021

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

R=danno@chromium.org

Review URL: https://codereview.chromium.org/12340113

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

(missing since r13761)

R=ulan@chromium.org
BUG=

Review URL: https://chromiumcodereview.appspot.com/12316158

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

While doing this, it became clear that quite a few functions should not be
static and should better live in various classes as instance methods, but I'll
leave this for a later CL.

BUG=v8:2487

Review URL: https://codereview.chromium.org/12314152

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

R=jkummerow@chromium.org
BUG=v8:2451

Review URL: https://chromiumcodereview.appspot.com/12342037

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

This fixes the deoptimizer to materialize arguments objects of correct
length even in cases where the actual argument values are unknown and
were optimized away by Crankshaft. This can happen if only the length
property or the identity of an arguments object is used.

R=svenpanne@chromium.org
BUG=chromium:163530
TEST=mjsunit/regress/regress-crbug-163530

Review URL: https://codereview.chromium.org/12335132

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

R=ulan@chromium.org
BUG=

Review URL: https://chromiumcodereview.appspot.com/12217066

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

R=ulan@chromium.org
BUG=

Review URL: https://chromiumcodereview.appspot.com/12177015

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

BUG=

Review URL: https://codereview.chromium.org/12310168

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

Both methods were among the top causes for TLS accesses.

BUG=v8:2487

Review URL: https://codereview.chromium.org/12319144

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

BUG=

Review URL: https://codereview.chromium.org/12313131

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

BUG=

Review URL: https://codereview.chromium.org/12207207

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

According to gprof, this was the #1 cause for TLS access during an Octane run.

BUG=v8:2487

Review URL: https://codereview.chromium.org/12317141

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

This was another top cause for TLS access.

BUG=v8:2487

Review URL: https://codereview.chromium.org/12340101

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

Review URL: https://codereview.chromium.org/12328136

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

R=yangguo@chromium.org

Review URL: https://chromiumcodereview.appspot.com/12314150

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

Previously, we would disassemble some VFP instructions like this:

  vmla.f64eq d16, d17, d18

This patch moves the condition to the right place:

  vmlaeq.f64 d16, d17, d18

Spotted by Rodolph Perfetta!

BUG=none

Review URL: https://chromiumcodereview.appspot.com/12335129
Patch from Hans Wennborg <hans@chromium.org>.

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

Review URL: https://codereview.chromium.org/12299009

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

Review URL: https://codereview.chromium.org/12317142

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

BUG=

Review URL: https://codereview.chromium.org/12301020

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

BUG=none

Review URL: https://chromiumcodereview.appspot.com/12319113
Patch from Hans Wennborg <hans@chromium.org>.

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

R=jkummerow@chromium.org

Review URL: https://codereview.chromium.org/12342033

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

R=ulan@chromium.org

Review URL: https://codereview.chromium.org/12321141

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

Port r13700 (587dc7c1)

BUG=

Review URL: https://codereview.chromium.org/12310087

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

Review URL: https://codereview.chromium.org/12328064

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

The patch is based on the previous one that was rolled out: https://code.google.com/p/v8/source/detail?r=12985

On Linux sampling for CPU profiler is initiated on the profiler event processor thread, other platforms to follow.

CPU profiler continues to use SamplingCircularQueue, we will replave it with a single sample buffer when Mac and Win ports support profiling on the event processing thread.

When --prof option is specified profiling is initiated either on the profiler event processor thread if CPU profiler is on or on the  SignalSender thread as it used to if no CPU profiles are being collected.

ProfilerEventsProcessor::ProcessEventsAndDoSample now waits in a tight loop, processing collected samples until sampling interval expires. To save CPU resources I'm planning to change that to use nanosleep as only one sample is expected in the queue at any point.

BUG=v8:2364

Review URL: https://codereview.chromium.org/12321046

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

r12883 was in complete because the library was included for host and
target. Restrict to just target.

BUG=chromium:158821

Review URL: https://chromiumcodereview.appspot.com/12314118
Patch from Yaron Friedman <yfriedman@chromium.org>.

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

BUG=v8:2509
TEST=mjsunit/regress/regress-1125,NavierStokes fails on Nexus 10.
R=mstarzinger@chromium.org

Review URL: https://chromiumcodereview.appspot.com/12314124

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

This changes FastCloneShallowObjectStub to be compiled independent of
the target architecture. It also adds tracing to the deoptimizer for
compiled stubs and contains some minor bugfixes.

R=danno@chromium.org

Review URL: https://codereview.chromium.org/12220074

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

The field is only accessed on the JS thread so it can be converted into bool.

BUG=None

Review URL: https://codereview.chromium.org/12340052

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

R=yangguo@chromium.org
BUG=

Review URL: https://codereview.chromium.org/12326120

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

The reason this test fails on ARM hardware but not on Intel hardware
(including the ARM simulator) is this:
'\xa0' is interpreted as a negative signed byte number. Casting it to
uc16 sign-extends it. The resulting string does not fit into a one-byte
string, thus a two-byte string is allocated.
For some reason the code compiled for ARM does not sign-extend, and 0xa0
fits into a one-byte string. Thus a one-byte string is allocated. Trying
to cast it to two-byte causes assertion failure.

BUG=

Review URL: https://chromiumcodereview.appspot.com/12319111

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

This moves the __proto__ property to Object.prototype and turns it into
a callback property actually present in the descriptor array as opposed
to a hack in the properties lookup. For now it still is a "magic" data
property using foreign callbacks and not an accessor property visible to
JavaScript.

The second effect of this change is that JSON.parse() no longer treats
the __proto__ property specially, it will be defined as any other data
property. Note that object literals still have their special handling.

R=rossberg@chromium.org
BUG=v8:621,v8:1949,v8:2441
TEST=mjsunit,cctest,test262

Review URL: https://codereview.chromium.org/12212011

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

R=ulan@chromium.org
BUG=

Review URL: https://chromiumcodereview.appspot.com/12210143

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

This speeds up isFrozen/isSealed checks on "normal" objects without
slowing down checks on frozen/sealed objects.

Though this ordering is not what ES5 specifies, the difference is not
observable (especially since the code bails out if the passed-in object
is a proxy).

Review URL: https://codereview.chromium.org/12340008

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

When there are interceptors on an object, it's possible to
end up with duplicate property names. But when all the names
are provided by v8, a collision is not possible, so we can
fast-path that case by not de-duping.

Also added better test coverage for interceptor API.

Review URL: https://codereview.chromium.org/12314081

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