This CL enables RelocInfo pointers which live in the constant pool to be treated
as normal pointers by the slot buffer, avoiding the requirement of creating fake
RelocInfo objects during UpdateSlots() in order to update these slots.  This
is possible because constant pool entries are just pointers and don't require
the RelocInfo machinary to be updated.

EmbeddedObject constant pool entries can be added untyped to the slot buffer,
while code targets are still typed in order to correctly update the target
address based on the relocated code object.

Note: this is required in order to enable OOL constant pool support on Arm, but
should be benifitial for the current inline constant pool used by Arm code.

R=mstarzinger@chromium.org

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

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

This CL updates
StoreBuffer::FindPointersToNewSpaceOnPage such that it skips  constant pool array objects.  Constant Pool Arrays should never have pointers to the new space and might contain pointers to the FreeSpace map (e.g., due to code
being generated which needs to do a map-check on a FreeSpace object) which would incorrectly treated as a filler object if processed by FindPointersToNewSpaceOnPage().

R=hpayer@chromium.org

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

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

This replaces Tmp0() and Tmp1() with a more flexible scratch register
pool. A scope-based utility can temporarily acquire registers from this
pool as needed.

We no longer have to worry about whether to use Tmp0(), Tmp1() or
something else; the scope can just get the next available scratch
register.

BUG=
R=jochen@chromium.org, rmcilroy@chromium.org

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

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

Port r19744 (b05fa4a)

BUG=
R=plind44@gmail.com

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

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

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

This reverts commit r19711 for breaking WebKit tests.
http://build.chromium.org/p/tryserver.chromium/builders/win_rel/builds/278551/steps/content_browsertests/logs/AccessibilityMessagesQueueWhileSwappedOut

TBR=ulan@chromium.org

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

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

Advance() always checks for stack overflow. If stack indeed overflowed,
current() would hold the kEndMarker. ParseOctalLiteral does not expect
this in the assertion, which causes assertion failure.

R=mvstanton@chromium.org
BUG=350865
LOG=N

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

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

R=mstarzinger@chromium.org
BUG=

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

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

R=jkummerow@chromium.org

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

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

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

BUG=v8:3208
LOG=N
R=machenbach@chromium.org

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

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

R=jkummerow@chromium.org
BUG=v8:3118
LOG=N

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

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

BUG=
R=bmeurer@chromium.org

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

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

Import Blink layout tests for Promises.
We omitted some tests (for example workers tests).
We fixed some wrong test expectations.

BUG=347095
LOG=N
R=rossberg@chromium.org

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

Patch from Yutaka Hirano <yhirano@chromium.org>.

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

BUG=
R=mvstanton@chromium.org

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

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

This fixes two issues:
- Update externalize-string-extension to the behavior of the API (see r18285)
- Convert cons strings in old pointer space to short external strings as
  expected by Heap::AllowedToBeMigrated, regardless of alignment.

R=mstarzinger@chromium.org

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

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

Promise.all and Promise.race should reject the returned Promise if an
invalid parameter is given.
Since they don't support iterable now, they should reject the Promise
if a non-array parameter is given.

BUG=347453
LOG=Y
R=rossberg@chromium.org

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

Patch from Yutaka Hirano <yhirano@chromium.org>.

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

The tests were using different kind of constructs for achieving the same
thing. This makes refactoring the compilation API more difficult than it should
be.

cctest.h already contained helpers for compiling and running scripts, but they
were not used consistently.

For example, all these were used for running scripts:

v8::Script::Compile(v8_str("foo"))->Run();
v8::Script::Compile(v8::String::NewFromUtf8(isolate, "foo))->Run();
CompileRun(v8_str("foo"));
CompileRun(v8::String::NewFromUtf8(some_way_to_get_isolate(), "foo"));
v8::Local<v8::Script> script = any_of_the_above; script->Run();

Most of the tests just want to run a script (which is in const char*) and don't
care about how the v8::String is constructed or passed to the compiler API. Using
the helpers makes the test more readable and reduces boilerplate code which is
unrelated to what the test is testing.

R=dcarney@chromium.org
BUG=

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

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

As specified, they should unwrap resolution values recursively.

BUG=347427
LOG=Y
R=rossberg@chromium.org

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

Patch from Yutaka Hirano <yhirano@chromium.org>.

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

It is not safe to access the range for an SSA value
after range analysis.

BUG=v8:3204
LOG=y
R=svenpanne@chromium.org

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

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

Notes:
- The regexp in the ParseObjectLiteralComment was wrong, made it less wrong (
it's still wrong since trailing commas are not required / allowed).
- Change in logic: In case we have "get somekeyword() { }", the "somekeyword"
was not logged as a symbol by PreParser and not expected in the preparser data
by Parser. This is unnecessary complication; in other contexts where keywords
are allowed as identifiers, they are logged as symbols (see
ParseIdentifierName).

BUG=v8:3126
LOG=N
R=ulan@chromium.org

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

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

Fixed the flooring div bug and added a test case.

R=svenpanne@chromium.org

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

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

R=dslomov@chromium.org
TBR=dslomov@chromium.org

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

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

Contributed by fmeawad@chromium.org

R=yangguo@chromium.org

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

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

R=verwaest@chromium.org

BUG=

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

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

Also use temporary wrapper functions where possible to mark progress.

R=ishell@chromium.org

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

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

R=jarin@chromium.org

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

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

R=rossberg@chromium.org

BUG=

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

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

Allow Object::InternalFieldCount and Object::GetAlignedPointerFromInternalField to be called from Persistent classes

R=svenpanne@chromium.org

BUG=

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

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

Goto does not emit a jump if the target is the next emitted block.
However, if there is an unreachable block between Goto and the jump
target, we still emit a jump even though the unreachable block is
not actually emitted. That jump is unnecessary.

R=jkummerow@chromium.org

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

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

R=jarin@chromium.org

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

Patch from Cosmin Truta <ctruta@gmail.com>.

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

Also refactor the related code in preparation for fixing the
range analysis.

BUG=v8:3204
LOG=y
R=svenpanne@chromium.org

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

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

Original Issue: https://codereview.chromium.org/183683022/

TBR=rossberg
BUG=v8:2409
LOG=Y

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

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

TBR=rossberg
BUG=

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

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

R=rossberg@chromium.org, rossberg
BUG=v8:2409
LOG=Y

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

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

Port r19715 (0d6d244)

Original commit message:
Lithium currently supports 3 division-like operations on integral
operands: "Normal" division (rounding towards zero), flooring division
(rounding towards -Infinity) and modulus calculation (the counterpart
for the "normal" division). For divisors which are a power of 2, one can
efficiently use some bit fiddling to avoid the actual division for such
operations. This CL cleanly splits off these operations into separate
Lithium instructions, making the code much more maintainable and more
consistent across platforms.

There are 2 basic variations of these bit fiddling algorithms: One
involving branches and a seemingly more clever one without branches.
Choosing between the two is not as easy as it seems: Benchmarks (and
probably real-world) programs seem to favor positive dividends,
registers and shifting units are sometimes scarce resources, and branch
prediction is quite good in modern processors. Therefore only the
"normal" division by a power of 2 is implemented in a branch-free
manner, this seems to be the best approach in practice. If this turns
out to be wrong, we can easily and locally change this.

BUG=
R=plind44@gmail.com

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

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

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

Port r19704 (120500a)

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

BUG=
R=plind44@gmail.com

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

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

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

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

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

BUG=
R=ulan@chromium.org

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

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

BUG=None
TBR=mstarzinger@chromium.org

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

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

AllocationTracker now maintains a map from address range to stack trace that allocated the range. When snapshot is generated the map is used to find construction stack trace for an object using its address.

BUG=chromium:277984
LOG=Y
R=alph@chromium.org, mstarzinger@chromium.org

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

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