(1) When we have just normalized and re-fastified a map, we don't need to copy it again to set the is_prototype bit.
(2) When defining accessors causes a non-prototype object to go slow, don't force re-fastification.

BUG=v8:3267
LOG=n
R=verwaest@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25221}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25221 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This implements correct semantics for "extensible" top level lexical scope.
The entire lexical scope is represented at runtime by GlobalContextTable, reachable from native context and accumulating global contexts from every script loaded into the context.

When the new script starts executing, it does the following validation:
- checks the GlobalContextTable and global object (non-configurable own) properties against the set of declarations it introduces and reports potential conflicts.
- invalidates the conflicting PropertyCells on global object, so that any code depending on them will miss/deopt causing any contextual lookups to be reexecuted under the new bindings
- adds the lexical bindings it introduces to the GlobalContextTable

Loads and stores for contextual lookups are modified so that they check the GlobalContextTable before looking up properties on global object, thus implementing the shadowing of global object properties by lexical declarations.

R=adamk@chromium.org, rossberg@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25220}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25220 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=verwaest@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25219}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25219 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Port c01061044028f7a31ba51496e44900481005eb38
Port r25207

BUG=
R=mvstanton@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25218}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25218 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=jarin@chromium.org
TEST=cctest/test-scheduler/NestedFloatingDiamondWithLoop

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

Cr-Commit-Position: refs/heads/master@{#25217}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25217 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Happily, this fixes WIN64 failures too.

BUG=
R=titzer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25216}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25216 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

The spec explicitly forbids them. V8 never handled them properly either, just
the Scanner accepted them (it had code to add them literally to the
LiteralBuffer) and later on, Regexp constructor disallowed them.

According to the spec, unicode escapes in regexp flags should be an early error
("It is a Syntax Error if IdentifierPart contains a Unicode escape sequence.").

Note that Scanner is still more relaxed about regexp flags than the
spec. Especially, it accepts any identifier parts (not just a small set of
letters) and doesn't check for duplicates.

R=rossberg@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25215}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25215 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=
R=mstarzinger@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25214}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25214 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=
R=ulan@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25213}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25213 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=
R=ulan@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25212}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25212 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

SystemTimeToTzSpecificLocalTime doesn't work correctly inside Chrome sandbox.

BUG=chromium:417640
LOG=Y
R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25211}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25211 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=bmeurer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25210}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25210 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

cp is handled by the register allocator and doesn't necessarily hold the
context pointer on arm64.

R=bmeurer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25209}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25209 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=
R=ulan@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25208}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25208 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=
R=bmeurer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25207}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25207 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=titzer@chromium.org
TEST=test-run-inlining/InlineTwiceDependentDiamond

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

Cr-Commit-Position: refs/heads/master@{#25205}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25205 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=v8:2783
LOG=Y
R=dslomov@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25204}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25204 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

TBR=mstarzinger@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#25203}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25203 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Port 724a15e8bf3fb8697a950c8e0f96158c8e56ec71
Port r25187

The HydrogenCodeStub is too expensive and there's no easy way to reduce
this cost, so turning it into a PlatformCodeStub solves that problem
until we can use TurboFan for code stubs.

TEST=mjsunit
BUG=
R=dusan.milosavljevic@imgtec.com

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

Cr-Commit-Position: refs/heads/master@{#25202}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25202 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=bmeurer@chromium.org

BUG=

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

Cr-Commit-Position: refs/heads/master@{#25201}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25201 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=mstarzinger@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#25200}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25200 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

- JSBitwiseOr(x, 0) => Word32Or(NumberToInt32(JSToNumber(x)), 0)
- JSMultiply(x, 1) => NumberMultiply(JSToNumber(x), 1)

R=jarin@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25198}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25198 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=mstarzinger@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#25197}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25197 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This does the following optimization during ChangeLowering:

 ChangeTaggedToFloat64(JSToNumber(x)) =>
   if IsSmi(x) then ChangeSmiToFloat64(x)
   else let y = JSToNumber(x) in
     if IsSmi(y) then ChangeSmiToFloat64(y)
     else LoadHeapNumberValue(y)

Also cleanup/rearrange some code duplication in ChangeLowering.

R=dcarney@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25195}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25195 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

TBR=titzer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25194}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25194 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=jarin@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#25193}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25193 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=
R=jarin@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25192}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25192 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=
R=bmeurer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25191}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25191 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Allow JSArray fast moving elements even if the array's proto isn't Array.prototype in original state
Otherwise array builtins don't work on internal arrays.

BUG=v8:3681
LOG=n
R=machenbach@chromium.org, mvstanton@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25190}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25190 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

TEST=unittests
R=dcarney@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25189}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25189 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=titzer@chromium.org
TEST=cctest/test-scheduler/RPOLoop

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

Cr-Commit-Position: refs/heads/master@{#25188}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25188 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

The HydrogenCodeStub is too expensive and there's no easy way to reduce
this cost, so turning it into a PlatformCodeStub solves that problem
until we can use TurboFan for code stubs.

TEST=mjsunit
R=mvstanton@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25187}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25187 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=3681
LOG=n
TBR=mvstanton@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25186}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25186 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=chromium:430846
LOG=N
R=verwaest@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25185}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25185 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=jarin@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25184}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25184 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

TBR=machenbach@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25183}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25183 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

The idea behind of this solution is to use the existing "relocation info" instead of consumption the CodeLinePosition events emitted by the V8 compilers.
During generation code and relocation info are generated simultaneously.
When code generation is done you each code object has associated "relocation info".
Relocation information lets V8 to mark interesting places in the generated code: the pointers that might need to be relocated (after garbage collection),
correspondences between the machine program counter and source locations for stack walking.

This patch:
1. Add more source positions info in reloc info to make it suitable for source level mapping.
The amount of data should not be increased dramatically because (1) V8 already marks interesting places in the generated code and
(2) V8 does not write redundant information (it writes a pair (pc_offset, pos) only if pos is changed and skips other).
I measured it on Octane benchmark - for unoptimized code the number of source positions may achieve 2x ('lin_solve' from NavierStokes benchmark).

2. When a sample happens, CPU profiler finds a code object by pc, then use its reloc info to match the sample to a source line.
If a source line is found that hit counter is increased by one for this line.

3. Add a new public V8 API to get the hit source lines by CDT CPU profiler.
Note that it's expected a minor patch in Blink to pack the source level info in JSON to be shown.

4.Add a test that checks how the samples are distributed through source lines.
It tests two cases: (1) relocation info created during code generation and (2) relocation info associated with precompiled function's version.

Patch from Denis Pravdin <denis.pravdin@intel.com>;

R=svenpanne@chromium.org, yurys@chromium.org

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

Patch from Weiliang <weiliang.lin@intel.com>.

Cr-Commit-Position: refs/heads/master@{#25182}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25182 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=jarin@chromium.org

TEST=cctest/test-scheduler/LoopedFloatingDiamond2

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

Cr-Commit-Position: refs/heads/master@{#25181}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25181 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

TEST=cctest/test-changes-lowering,mjsunit/asm,unittests
R=jarin@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25180}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25180 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

The bug has always been there: when the parser is operating in the "immediately
internalize" mode and calls GetString, we get FlatContent of a string and then
do heap allocation.

The bug was uncovered by https://codereview.chromium.org/693803004/ (which put
the parser to the "immediately internalize" mode more often), but looking at the
code, it's possible that it can happen in other cases too.

This CL makes AstValueFactory handle this situation gracefully: it won't try to
internalize inside GetString(Handle<String>); it's unnecessary anyway since we
have the Handle<String> already.

BUG=
R=rossberg@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#25179}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25179 ce2b1a6d-e550-0410-aec6-3dcde31c8c00