This models function local control flow through try-finally constructs
using a token dispatch mechanism. All paths through the finally block
are assigned a token, at the end of the finally block a switch construct
dispatches according to this token.

R=oth@chromium.org,rmcilroy@chromium.org
BUG=v8:4674
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#33465}

Break and continue operations need to pop the context chain to the
correct context before jumping to the target.

BUG=v8:4280,v8:4678
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#33464}

This fixes the broken return address when the exception handler within
interpreted bytecode is being entered via stack unwinding. The address
in question will never actually be taken, but our stack walker uses this
address to determine whether a frame is interpreted.

R=rmcilroy@chromium.org
TEST=cctest/test-interpreter/InterpreterTryCatch
BUG=v8:4674
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#33463}

In d8, run with --runtime-call-stats and it will output the stats when d8 finishes.

In Chrome, run the following: (only on trusted code, this punches *massive* security hole into Chrome)

chrome --js-flags="--runtime-call-stats --allow-natives-syntax"

To get the stats in the console, just run

console.log(%GetAndResetRuntimeCallStats());

To output stats every second:

setInterval(function() { console.log(%GetAndResetRuntimeCallStats()); }, 1000)

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

Cr-Commit-Position: refs/heads/master@{#33462}

When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.

Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.

This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.

BUG=v8:4267
LOG=Y

Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f
Cr-Commit-Position: refs/heads/master@{#33438}

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

Cr-Commit-Position: refs/heads/master@{#33461}

We already had hand-written optimized code for %_ToName in fullcodegen,
but the optimizing compilers always went to the runtime for %_ToName,
which is pretty bad for many of our builtins. So this CL moves the
existing native code to a ToNameStub (similar to the existing
ToStringStub), and uses the ToNameStub consistently in all compilers to
actually implement %_ToName.

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

Cr-Commit-Position: refs/heads/master@{#33460}

Revert of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #1 id:1 of https://codereview.chromium.org/1612413003/ )

Reason for revert:
let me quickly revert the revert, wut?
Goal: my CL should not be in the tree!

Original issue's description:
> Reland of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #1 id:1 of https://codereview.chromium.org/1619803003/ )
>
> Reason for revert:
> the deopt issues have been taken care of by benedikt
>
> Original issue's description:
> > Revert of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #10 id:180001 of https://codereview.chromium.org/1608523002/ )
> >
> > Reason for revert:
> > tanks for-in significantly
> >
> > Original issue's description:
> > > [runtime] Do not use the enum-cache for keys retrieval.
> > >
> > > Currently we fail to properly handle shadowed properties. If the
> > > receiver defines a non-enumerable property that reappears on the
> > > prototype as enumerable it incorrectly shows up in [[Enumerate]].
> > > By extending the KeyAccumulator to track non-enumerable properties
> > > we can now properly filter them out when seeing them further up in
> > > the prototype-chain.
> > >
> > > BUG=v8:705
> > > LOG=y
> > >
> > > Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> > > Cr-Commit-Position: refs/heads/master@{#33405}
> >
> > TBR=jkummerow@chromium.org,bmeurer@chromium.org
> > # Not skipping CQ checks because original CL landed more than 1 days ago.
> > BUG=v8:705
> > LOG=n
> >
> > Committed: https://crrev.com/6e0573c6fff1c3041bab106d1197ab1b64aa9a6a
> > Cr-Commit-Position: refs/heads/master@{#33443}
>
> TBR=jkummerow@chromium.org,bmeurer@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:705
>
> Committed: https://crrev.com/5569e270eda517b5ea74e3a7676b3230cbe2f7a9
> Cr-Commit-Position: refs/heads/master@{#33458}

TBR=jkummerow@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:705

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

Cr-Commit-Position: refs/heads/master@{#33459}

Reland of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #1 id:1 of https://codereview.chromium.org/1619803003/ )

Reason for revert:
the deopt issues have been taken care of by benedikt

Original issue's description:
> Revert of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #10 id:180001 of https://codereview.chromium.org/1608523002/ )
>
> Reason for revert:
> tanks for-in significantly
>
> Original issue's description:
> > [runtime] Do not use the enum-cache for keys retrieval.
> >
> > Currently we fail to properly handle shadowed properties. If the
> > receiver defines a non-enumerable property that reappears on the
> > prototype as enumerable it incorrectly shows up in [[Enumerate]].
> > By extending the KeyAccumulator to track non-enumerable properties
> > we can now properly filter them out when seeing them further up in
> > the prototype-chain.
> >
> > BUG=v8:705
> > LOG=y
> >
> > Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> > Cr-Commit-Position: refs/heads/master@{#33405}
>
> TBR=jkummerow@chromium.org,bmeurer@chromium.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=v8:705
> LOG=n
>
> Committed: https://crrev.com/6e0573c6fff1c3041bab106d1197ab1b64aa9a6a
> Cr-Commit-Position: refs/heads/master@{#33443}

TBR=jkummerow@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:705

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

Cr-Commit-Position: refs/heads/master@{#33458}

NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

Cr-Commit-Position: refs/heads/master@{#33457}

The internal index used to implement for-in can never leave the
valid smi range, so there's no need to actually check for overflow
in Crankshaft. In fact the overflow only triggered a false alert
in the deopt fuzzer.

R=jarin@chromium.org
BUG=v8:3650
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#33456}

This simplifies correlating offsets with the output from
--print-opt-code, which outputs offsets in decimal.

We keep the hex output since branch instructions in the perf dump use
hex labels. We just include the decimal offset along with the hex offset.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#33455}

Revert "Revert of [turbofan] optimize spills in defered blocks (patchset #3 id:240001 of https://codereview.chromium.org/1551013002/ )"

This reverts commit 7f62e122.

The regressions reported in the bug below appear to be bogus, and
caused by chromium:579503

BUG=chromium:579900
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#33454}

R=jarin@chromium.org
BUG=v8:3650
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#33453}

Show tick count, besides the percentage spent on an
instruction. Aids perf investigations where we deal with
stalls, for example. Percentage-wise, the execution appears
distributed similarly, but the regression becomes more
apparent in the tick counts.

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

Cr-Commit-Position: refs/heads/master@{#33452}

Rolling v8/buildtools to cf8c4332f5c9d0da4b4782d7f0122df74a16819b

Rolling v8/tools/clang to e47364ad9fb37e8255a7a5cdf7891781b3f8256e

Rolling v8/tools/swarming_client to 0b908f18767c8304dc089454bc1c91755d21f1f5

TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33451}

BUG=v8:4663
LOG=N
TBR=hpayer@chromium.org
R=ljharb@gmail.com, rossberg@chromium.org, adamk@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33450}

Revert of [profiler] Implement POC Sampling Heap Profiler (patchset #12 id:220001 of https://codereview.chromium.org/1555553002/ )

Reason for revert:
The random nature of the tests caused the following buildbot to fail: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/4724/steps/Check/logs/stdio

Original issue's description:
> [profiler] Implement POC Sampling Heap Profiler
>
> This implements a proof-of-concept sampling based heap profiler inspired by
> tcmalloc's heap profiler [1] and Go's mprof/memprofile [2].
>
> The basic idea is the sample allocations using a randomized Poisson process. At
> any point in time we can cheaply request the set of live sample objects that
> should be a representative sample of heap. Samples include stack-traces from the
> allocation sites, making this an effective tool for memory leak debugging.
>
> Unlike AllocationTracking, this is intended to be cheap and usable online in
> production.
>
> The proof-of-concept is only sampling new-space allocations at this point.
> Support for sampling paged space and native allocations is anticipated in the
> future.
>
> [1] http://goog-perftools.sourceforge.net/doc/heap_profiler.html
> [2] http://blog.golang.org/profiling-go-programs
>
> Committed: https://crrev.com/e5a9947811db9c9e23557dbad27f8b8a349b3262
> Cr-Commit-Position: refs/heads/master@{#33448}

TBR=jochen@chromium.org,alph@chromium.org,hpayer@chromium.org,yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

Cr-Commit-Position: refs/heads/master@{#33449}

This implements a proof-of-concept sampling based heap profiler inspired by
tcmalloc's heap profiler [1] and Go's mprof/memprofile [2].

The basic idea is the sample allocations using a randomized Poisson process. At
any point in time we can cheaply request the set of live sample objects that
should be a representative sample of heap. Samples include stack-traces from the
allocation sites, making this an effective tool for memory leak debugging.

Unlike AllocationTracking, this is intended to be cheap and usable online in
production.

The proof-of-concept is only sampling new-space allocations at this point.
Support for sampling paged space and native allocations is anticipated in the
future.

[1] http://goog-perftools.sourceforge.net/doc/heap_profiler.html
[2] http://blog.golang.org/profiling-go-programs

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

Cr-Commit-Position: refs/heads/master@{#33448}

Port f48bf12f

Original commit message:
    The PrepareId bailout location was used incorrectly in Crankshaft and,
    as it turns out, is not required anyway (once you do it right). Also
    there was some premature optimization going on with the CheckEnumCache
    (trying to load null from roots only once), plus we can be smarter about
    the null/undefined check anyway.

    The idea behind this changes is to prepare unification of the two
    different ForInPrepare implementations that we now have, with the end
    result being that we only use the new implementation that was recently
    added for the interpreter.

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:3650
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#33447}

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

Cr-Commit-Position: refs/heads/master@{#33446}

BUG=v8:4696
LOG=N
NOTRY=true
TBR=rossberg, nickie

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

Cr-Commit-Position: refs/heads/master@{#33445}

Revert of Array length reduction should throw in strict mode if it can't delete an element. (patchset #7 id:220001 of https://codereview.chromium.org/1587073003/ )

Reason for revert:
[Sheriff] Breaks layout tests. Please fix upstream.
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/4077

Original issue's description:
> Array length reduction should throw in strict mode if it can't delete an element.
>
> When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
>
> Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
>
> This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
>
> BUG=v8:4267
> LOG=Y
>
> Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f
> Cr-Commit-Position: refs/heads/master@{#33438}

TBR=verwaest@chromium.org,ishell@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4267

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

Cr-Commit-Position: refs/heads/master@{#33444}

Revert of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #10 id:180001 of https://codereview.chromium.org/1608523002/ )

Reason for revert:
tanks for-in significantly

Original issue's description:
> [runtime] Do not use the enum-cache for keys retrieval.
>
> Currently we fail to properly handle shadowed properties. If the
> receiver defines a non-enumerable property that reappears on the
> prototype as enumerable it incorrectly shows up in [[Enumerate]].
> By extending the KeyAccumulator to track non-enumerable properties
> we can now properly filter them out when seeing them further up in
> the prototype-chain.
>
> BUG=v8:705
> LOG=y
>
> Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> Cr-Commit-Position: refs/heads/master@{#33405}

TBR=jkummerow@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:705
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#33443}

Motivated by finding a bug in a larger module, this CL adds the ability
to dump out a byte-by-byte, nested view of the decoded AST. This
byte-by-byte output uses the opcode enum to make it readable, but is
suitable for pasting into a byte[] in C or JS and thus making a regression
test.

Also fix a bug; the case of running out of registers for indirect calls.

R=ahaas@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#33442}

ParseArguments already does the rewriting.

R=rossberg@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#33441}

R=titzer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33440}

There's no need to have HMapEnumLength as a dedicated instruction,
as it can be expressed using a HLoadNamedField plus an HBitwiseAnd
operation.

R=jarin@chromium.org
BUG=v8:3650
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#33439}

When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.

Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.

This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.

BUG=v8:4267
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#33438}

We divide character ranges into
- BMP, matched normally.
- non-BMP, matched as alternatives of surrogate pair ranges.
- lone surrogates, matched with lookaround assertion that its indeed lone.

R=erik.corry@gmail.com
BUG=v8:2952
LOG=N

Committed: https://crrev.com/ea820ad5fa282a323a86fe20e64f83ee67ba5f04
Cr-Commit-Position: refs/heads/master@{#33432}

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

Cr-Commit-Position: refs/heads/master@{#33437}

These features are not used by devtools and consequently not
exposed through the devtools protocol. They make the debugger
unnecessarily complex. If we decide that we need this, we should
implement this on a higher layer.

R=bmeurer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33436}

Also restrict how many pages are swept during slow path allocation.

BUG=chromium:524425
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#33435}

Revert of [regexp] implement character classes for unicode regexps. (patchset #11 id:220001 of https://codereview.chromium.org/1578253005/ )

Reason for revert:
Compile failure on arm.

https://build.chromium.org/p/client.v8/builders/V8%20Arm%20-%20debug%20builder/builds/7341/steps/compile/logs/stdio

Original issue's description:
> [regexp] implement character classes for unicode regexps.
>
> We divide character ranges into
> - BMP, matched normally.
> - non-BMP, matched as alternatives of surrogate pair ranges.
> - lone surrogates, matched with lookaround assertion that its indeed lone.
>
> R=erik.corry@gmail.com
> BUG=v8:2952
> LOG=N
>
> Committed: https://crrev.com/ea820ad5fa282a323a86fe20e64f83ee67ba5f04
> Cr-Commit-Position: refs/heads/master@{#33432}

TBR=littledan@chromium.org,erik.corry@gmail.com,erikcorry@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:2952

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

Cr-Commit-Position: refs/heads/master@{#33434}

It was not properly rewriting three cases:

-   [...[42]][0]
-   [...[42]].length
-   [...[42]] `foo`    (which is a type error)

R=rossberg@chromium.org
BUG=v8:4696
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#33433}

We divide character ranges into
- BMP, matched normally.
- non-BMP, matched as alternatives of surrogate pair ranges.
- lone surrogates, matched with lookaround assertion that its indeed lone.

R=erik.corry@gmail.com
BUG=v8:2952
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#33432}

Revert of [turbofan] optimize spills in defered blocks (patchset #3 id:240001 of https://codereview.chromium.org/1551013002/ )

Reason for revert:
Regresses lots of benchmarks: https://crbug.com/579900

Original issue's description:
> [turbofan] optimize spills in defered blocks
>
> Up to now, for ranges spilled in deferred blocks, we would spill every
> time a range would switch from using a register to spill slots. That can
> be redundant, leading to avoidable code size  cost.
>
> This change addresses this issue, by performing the spills as early as
> possible.
>
> BUG=
>
> Committed: https://crrev.com/7c54dc33855b8ac31f26b309671f9b5481a74376
> Cr-Commit-Position: refs/heads/master@{#33413}

TBR=bmeurer@chromium.org,mtrofin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

Cr-Commit-Position: refs/heads/master@{#33431}

BUG=

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

Cr-Commit-Position: refs/heads/master@{#33430}

A break location is considered muted if it has break points, but their
conditions all evaluate to false. Aside from not triggering break
events, debugger statements and exceptions are also ignored.

R=verwaest@chromium.org
BUG=chromium:429167
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#33429}

  port f48bf12f (r33426)

  original commit message:
  The PrepareId bailout location was used incorrectly in Crankshaft and,
  as it turns out, is not required anyway (once you do it right). Also
  there was some premature optimization going on with the CheckEnumCache
  (trying to load null from roots only once), plus we can be smarter about
  the null/undefined check anyway.

  The idea behind this changes is to prepare unification of the two
  different ForInPrepare implementations that we now have, with the end
  result being that we only use the new implementation that was recently
  added for the interpreter.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#33428}

When a slow mode for-in loop is compiled with Crankshaft we
unconditionally deoptimize when we hit an object with a usable
enum-cache (which is currently hidden by another CL), and obviously
we don't learn anything from that.

R=jarin@chromium.org
BUG=v8:3650
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#33427}

The PrepareId bailout location was used incorrectly in Crankshaft and,
as it turns out, is not required anyway (once you do it right). Also
there was some premature optimization going on with the CheckEnumCache
(trying to load null from roots only once), plus we can be smarter about
the null/undefined check anyway.

The idea behind this changes is to prepare unification of the two
different ForInPrepare implementations that we now have, with the end
result being that we only use the new implementation that was recently
added for the interpreter.

R=jarin@chromium.org
BUG=v8:3650
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#33426}