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}

  port 0b3066b8 (r33414)

  original commit message:
  This implements a first prototype of stack unwinding for interpreted
  frames. The unwinding machinery performs a range-based lookup in the
  given handler table and potentially continues dispatching at the handler
  offset. Note that this does not yet correctly restore the context to the
  correct value when the handler is being entered.

BUG=

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

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

  port 2dde677f (r33386)

  original commit message:
  This is the ia32/x64 version of https://codereview.chromium.org/873703002,
  which fixed the same problem on arm/arm64.

BUG=

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

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

  port d1d01964 (r33410)

  original commit message:
  The motivation for this is that CompilationInfo really shouldn't
  explicitly know anything about CodeStubs. This is evident in
  the TurboFan stubs pipeline, which only needs to pass down
  information about Code::Flags to the code generator and not
  any of the CallInterfaceDescriptor silliness that Hydrogen has
  to push around, since TF has the Linkage class that
  encapsulates everything that is needed for the stub ABI. So,
  instead of threading CodeStub machinery through the TF stub
  pipeline, it is now removed from CompilationInfo and replaced
  by only the explicit bits needed both by the Crankshaft and
  TF pipelines in code generation.

BUG=

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

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

Rolling v8/build/gyp to aa0301be5a241c2972f90ce2a08097b63c916390

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

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

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

R=titzer@chromium.org,aseemgarg@chromium.org
BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=test-asm-validator, asm-wasm.js
LOG=N

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

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

Although the `for..in` statement allows Expressions to define the
iterator, only an AssignmentExpression may occupy this position in the
`for..of` statement.

BUG=v8:4692
LOG=N
R=adamk@chromium.org

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

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

Remove an unnecessary is_static argument to ParsePropertyName (the caller
already has easy access to that information) and inline
ParseIdentifierNameOrGetOrSet into its only caller.

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

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

Port 0b3066b8

Original commit message:
    This implements a first prototype of stack unwinding for interpreted
    frames. The unwinding machinery performs a range-based lookup in the
    given handler table and potentially continues dispatching at the handler
    offset. Note that this does not yet correctly restore the context to the
    correct value when the handler is being entered.

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

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

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

The Object.getOwnPropertyNames method always calls into C++ anyway,
so there's no point in having the JavaScript wrapper around at all.

Drive-by-fix: Inline GetOwnEnumerablePropertyNames into its single
call site.

CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_chromium_rel_ng
R=yangguo@chromium.org

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

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

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

We no longer have the concept of "JS builtins" exposed to handwritten
native code, so there's no need to keep the InvokeBuiltin macro around.

R=mstarzinger@chromium.org

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

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

This change improves performance for the common case of
Object.getOwnPropertyDescriptor by up 3x-4x, where we just
return a property descriptor object for a regular data or
accessor property.

CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_chromium_rel_ng
R=yangguo@chromium.org

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

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

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

This implements a first prototype of stack unwinding for interpreted
frames. The unwinding machinery performs a range-based lookup in the
given handler table and potentially continues dispatching at the handler
offset. Note that this does not yet correctly restore the context to the
correct value when the handler is being entered.

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

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

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

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=

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

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

Platforms which do not provide rounding instructions (like x64 without
sse4.1, arm before v8) fall back to this new soft float inplementation.

BUG=575379

LOG=Y

R=titzer@chromium.org

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

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

R=ahaas@chromium.org,bradnelson@chromium.org
LOG=Y
BUG=chromium:575167

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

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