Port r21481 (5973b48)

Original commit message:
The FastNewContextStub always allocates in new space, so we don't
need to update the write barrier when copying the parameters to
the newly allocated context.

BUG=
R=danno@chromium.org

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

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

This fixes failure on pidigit benchmark from web-shootout
after 840 digits are calculated.

TEST=
BUG=
R=plind44@gmail.com

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

Patch from Dusan Milosavljevic <Dusan.Milosavljevic@rt-rk.com>.

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

Port r21533 (736c779)

BUG=
R=plind44@gmail.com

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

Patch from Balazs Kilvady <kilvadyb@homejinni.com>.

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

R=mstarzinger@chromium.org
BUG=

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

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

Port r21517 (53d6507)

BUG=
R=plind44@gmail.com

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

Patch from Balazs Kilvady <kilvadyb@homejinni.com>.

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

> This will send an idle notification and a low memory notification after
> each test.
>
> For some reason it's not enough to send a low memory notification alone.
>
> BUG=none
> R=yangguo@chromium.org
> LOG=n

BUG=none
R=yangguo@chromium.org
LOG=n

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

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

R=mvstanton@chromium.org

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

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

R=danno@google.com, danno@chromium.org

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

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

R=verwaest@chromium.org

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

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

TBR=yangguo@chromium.org
BUG=

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

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

This reverts r21529.

TBR=jochen@chromium.org

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

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

BUG=none
R=marja@chromium.org
LOG=n

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

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

This will send an idle notification and a low memory notification after
each test.

For some reason it's not enough to send a low memory notification alone.

BUG=none
R=yangguo@chromium.org
LOG=n

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

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

This requires introducing proper bounds on all leaf types, so that intersection between bitsets and these types can be accurately represented. Extending a union also becomes more involved.

(On the upside, the modified union/intersect algorithm would now allow support for proper variance for function types.)

Not sure if it is worth landing this. Distributivity isn't really a crucial property for our use cases. It seems fine if intersection is slightly lossy.

R=bmeurer@chromium.org, jarin@chromium.org
BUG=

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

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

It's just an alias, and STATIC_ASSERT is used way more often

BUG=none
R=jkummerow@chromium.org
LOG=n

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

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

TBR=mstarzinger@chromium.org
BUG=3350
LOG=N

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

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

Port r21509 (78a54b0)

Original commit message:
This way an HStoreNamedField instruction can never deoptimize
itself, which is another important step towards a working
store elimination.

BUG=
R=plind44@gmail.com

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

Patch from Balazs Kilvady <kilvadyb@homejinni.com>.

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

R=ulan@chromium.org

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

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

When tracing, we abuse the map for marking, thereby mutating it.
FixedTypedArrayBase::size() uses the object's map, which causes crash.

R=mstarzinger@chromium.org

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

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

R=mvstanton@chromium.org

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

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

(This shouldn't happen in the first place, as by definition that callback would never be called. However, the referenced bug sorta looks like this happened. If so, the CHECK should help us pinpoint the culprit.)

R=jochen@chromium.org
BUG=368095
LOG=N

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

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

R=ulan@chromium.org

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

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

MemCopy is only meant for variable size, large (>64bytes) copies,
otherwise, it's probably slower than memcpy due to the call
overhead and the compiler can't optimize it away.

BUG=none
R=jkummerow@chromium.org
LOG=n

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

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

R=jochen@chromium.org

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

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

R=ulan@chromium.org, bmeurer@chromium.org

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

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

BUG=
R=mstarzinger@chromium.org

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

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

R=yangguo@chromium.org

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

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

http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN

The bug:
The code assumed that a weak Persistent whose weak callback is being
called would still be weak. That isn't true since the persistent is
un-weakened by the garbage collector before calling the weak callback. [1]

Specifically, PersistentValueMap would funnel all 'remove' actions
through its Release method, which uses PersistentBase::ClearWeak to
obtain the callback data. [2] For 'removes' caused by the weak callback,
ClearWeak always returns a NULL-pointer since by that time the weak
persistent was already un-weakend. The result was a memory leak in
the test, since the code to delete the weak callback data would
delete NULL.

The fix:
I explicity call Traits::DisposeCallbackData from the weak callback
with the data obtained from the v8::WeakCallbackData. To avoid invalid
calls to DisposeCallbackData, I also check whether this instance is
(still) weak before calling it. (That check could easily be elided
if it's expensive, for the price of having two 'remove' code paths.)

Severety:
Probably low. At least in Chromium, noone uses the API in a way to
trigger this; only the test does.

[1] https://code.google.com/p/chromium/codesearch#chromium/src/v8/src/global-handles.cc&q=global-handles.cc&sq=package:chromium&type=cs&l=231
[2] https://code.google.com/p/chromium/codesearch#chromium/src/v8/include/v8-util.h&sq=package:chromium&l=332-345

R=dcarney@chromium.org, dcarney

BUG=

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

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

BUG=
R=mstarzinger@chromium.org

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

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

Verified that arm builds locally.

BUG=none
TBR=jkummerow@chromium.org
LOG=n

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

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

BUG=
R=bmeurer@chromium.org, mvstanton@chromium.org

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

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

R=danno@chromium.org

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

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

This way an HStoreNamedField instruction can never deoptimize
itself, which is another important step towards a working
store elimination.

R=jarin@chromium.org

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

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

R=verwaest@chromium.org

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

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

R=jarin@chromium.org

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

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

TBR=jkummerow@chromium.org

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

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

TBR=jkummerow@chromium.org
LOG=n
BUG=none

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

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

Since both are jitted on some platforms and depend on codegen, they
don't belong to the platform abstraction. At the same time, I can't put
them to codegen.h, as this would introduce cyclic dependencies.

BUG=none
R=jkummerow@chromium.org
LOG=n

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

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

It's really more an OS-level information, and this way the default
platform doesn't depend on CPU-level details

BUG=none
R=yangguo@chromium.org
LOG=n

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

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

Port r21481 (5973b48)

Original commit message:
The FastNewContextStub always allocates in new space, so we don't
need to update the write barrier when copying the parameters to
the newly allocated context.

BUG=
R=plind44@gmail.com

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

Patch from Balazs Kilvady <kilvadyb@homejinni.com>.

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