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

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

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

NOTRY=true

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

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

- remove unused counters
- add "ic" prefix to all ic-counters
- add more counter: maps-created, global deopts (not used yet)

BUG=

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

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

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

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

Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of https://codereview.chromium.org/1668103002/ )

Reason for revert:
Must revert for now due to chromium api natives issues.

Original issue's description:
> Type Feedback Vector lives in the closure
>
> (RELAND: the problem before was a missing write barrier for adding the code
> entry to the new closure. It's been addressed with a new macro instruction
> and test. The only change to this CL is the addition of two calls to
> __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
> Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
> And Benedikt reviewed it as well.
>
> TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5
> Cr-Commit-Position: refs/heads/master@{#33741}

TBR=bmeurer@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/1670813005

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

Revert of PPC: Type Feedback Vector lives in the closure (patchset #1 id:1 of https://codereview.chromium.org/1671553002/ )

Reason for revert:
issues with chromium api natives, must revert for now, thanks.

Original issue's description:
> PPC: Type Feedback Vector lives in the closure
>
> Port bb31db3a
>
> Original commit message:
>     (RELAND: the problem before was a missing write barrier for adding the code
>     entry to the new closure. It's been addressed with a new macro instruction
>     and test. The only change to this CL is the addition of two calls to
>     __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
>
>     We get less "pollution" of type feedback if we have one vector per native
>     context, rather than one for the whole system. This CL moves the vector
>     appropriately.
>
>     We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
>     vector actually lives in the first slot of the literals array (indeed there is
>     great commonality between those arrays, they can be thought of as the same
>     thing). So we make greater effort to ensure there is a valid literals array
>     after compilation.
>
>     This meant, for performance reasons, that we needed to extend
>     FastNewClosureStub to support creating closures with literals. And ultimately,
>     it drove us to move the optimized code map lookup out of FastNewClosureStub
>     and into the compile lazy builtin.
>
>     The heap change is trivial so I TBR Hannes for it...
>     Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
>     And Benedikt reviewed it as well.
>
> R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
> BUG=
>
> Committed: https://crrev.com/753ad25efa4790ea7c80aceecfa223c3436ca36f
> Cr-Commit-Position: refs/heads/master@{#33753}

TBR=joransiu@ca.ibm.com,jyan@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com
# 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/1673623002

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

Revert of X87: Type Feedback Vector lives in the closure. (patchset #1 id:1 of https://codereview.chromium.org/1672643002/ )

Reason for revert:
Bugs with chromium api natives, must revert for now.

Original issue's description:
> X87: Type Feedback Vector lives in the closure.
>
>   port bb31db3a (r33741)
>
>   original commit message:
>   (RELAND: the problem before was a missing write barrier for adding the code
>   entry to the new closure. It's been addressed with a new macro instruction
>   and test. The only change to this CL is the addition of two calls to
>   __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
>
>   We get less "pollution" of type feedback if we have one vector per native
>   context, rather than one for the whole system. This CL moves the vector
>   appropriately.
>
>   We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
>   vector actually lives in the first slot of the literals array (indeed there is
>   great commonality between those arrays, they can be thought of as the same
>   thing). So we make greater effort to ensure there is a valid literals array
>   after compilation.
>
>   This meant, for performance reasons, that we needed to extend
>   FastNewClosureStub to support creating closures with literals. And ultimately,
>   it drove us to move the optimized code map lookup out of FastNewClosureStub
>   and into the compile lazy builtin.
>
>   The heap change is trivial so I TBR Hannes for it...
>   Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
>   And Benedikt reviewed it as well.
>
> BUG=
>
> Committed: https://crrev.com/25bfba9329b93cb8ebefe1446e024005a4227a93
> Cr-Commit-Position: refs/heads/master@{#33759}

TBR=chunyang.dai@intel.com,weiliang.lin@intel.com,zhengxing.li@intel.com
# 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/1673613002

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

Ports https://codereview.chromium.org/1671753002

It brings auth support (so developers can use 'isolate' if
they really want to) and adds *.pyc to default isolate
blacklist.

TBR=maruel@chromium.org,  vadimsh@chromium.org, stip@chromium.org
BUG=584073
LOG=n

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

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

The recently introduced desugaring of yield* renders this code dead.

BUG=

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

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

TBR=rossberg@chromium.org

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

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

  port dbd86408 (r33744)

  original commit message:
  Note: This is currently only used by yield*, we still need to support it in
  other places (such as for-of loops).  It can be used manually of course.

  (This CL does not touch the full-codegen implementation of yield* because that
  code is already dead.  The yield* desugaring already supports return and doesn't
  need to be touched.)

BUG=

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

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

  port bb31db3a (r33741)

  original commit message:
  (RELAND: the problem before was a missing write barrier for adding the code
  entry to the new closure. It's been addressed with a new macro instruction
  and test. The only change to this CL is the addition of two calls to
  __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)

  We get less "pollution" of type feedback if we have one vector per native
  context, rather than one for the whole system. This CL moves the vector
  appropriately.

  We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
  vector actually lives in the first slot of the literals array (indeed there is
  great commonality between those arrays, they can be thought of as the same
  thing). So we make greater effort to ensure there is a valid literals array
  after compilation.

  This meant, for performance reasons, that we needed to extend
  FastNewClosureStub to support creating closures with literals. And ultimately,
  it drove us to move the optimized code map lookup out of FastNewClosureStub
  and into the compile lazy builtin.

  The heap change is trivial so I TBR Hannes for it...
  Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
  And Benedikt reviewed it as well.

BUG=

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

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

  port 477e1336 (r33718)

  original commit message:

BUG=

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

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

R=bradnelson@chromium.org
BUG=https://bugs.chromium.org/p/v8/issues/detail?id=4203
TEST=asm-wasm.js
LOG=N

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

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

Adds a new runtime function, %DefineDataPropertyInLiteral, which
takes a fifth argument specifying whether the property and value
are syntactically such that the value is a function (or class)
literal that should have its name set at runtime.

The new runtime call also allows us to eliminate the now-redundant
%DefineClassMethod runtime function.

This should get much less ugly once we can desugar the "dynamic"
part of object literals in the parser (but that work is currently
blocked on having a performant way of desugaring literals).

BUG=v8:3699, v8:3761
LOG=n

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

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

Port 477e1336

R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

Port dbd86408

Original commit message:
    Note: This is currently only used by yield*, we still need to support it in
    other places (such as for-of loops).  It can be used manually of course.

    (This CL does not touch the full-codegen implementation of yield* because that
    code is already dead.  The yield* desugaring already supports return and doesn't
    need to be touched.)

R=neis@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:3566
LOG=y

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

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

Port bb31db3a

Original commit message:
    (RELAND: the problem before was a missing write barrier for adding the code
    entry to the new closure. It's been addressed with a new macro instruction
    and test. The only change to this CL is the addition of two calls to
    __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)

    We get less "pollution" of type feedback if we have one vector per native
    context, rather than one for the whole system. This CL moves the vector
    appropriately.

    We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
    vector actually lives in the first slot of the literals array (indeed there is
    great commonality between those arrays, they can be thought of as the same
    thing). So we make greater effort to ensure there is a valid literals array
    after compilation.

    This meant, for performance reasons, that we needed to extend
    FastNewClosureStub to support creating closures with literals. And ultimately,
    it drove us to move the optimized code map lookup out of FastNewClosureStub
    and into the compile lazy builtin.

    The heap change is trivial so I TBR Hannes for it...
    Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
    And Benedikt reviewed it as well.

R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

BUG=v8:4725
LOG=N
R=adamk@chromium.org, cbruni@chromium.org, rossberg@chromium.org

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

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

There might be several ExternalCallbackScope's created
during the native callback. Remove the assert that is not
aligned with that.

Moreover this iterator must work for any kind of
stacks including corrupted ones.

BUG=v8:4705
LOG=N

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

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

This bit was ostensibly being used to provide appropriate syntax
errors for invalid destructuring assignment patterns, but adding a
single call to RecordPatternError() (in place of
BindingPatternUnexpectedToken()) seems to have replaced the need for it.

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

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

Also various related cleanup in ParseVariableDeclarations(). The only
changes in logic are explained below:

  - We were redundantly checking for parenthesized binding patterns;
    these are already ruled out by BindingPatternUnexpectedToken()
    calls in the places where we hit an LPAREN.
  - There's no need to default-initialize a LET-mode variable in a
    for-each loop, just as there isn't for CONST or CONST_LEGACY
    (ParseForStatement will take care of properly initializing all
    of the above).

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

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

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

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

BUG=v8:4724, v8:1543
LOG=N

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

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

Port of class literal support from the
ast-graph-builder implementation.

R=rmcilroy@chromium.org,mstarzinger@chromium.org
BUG=v8:4280,v8:4682
LOG=N

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

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

R=rmcilroy@chromium.org

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

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

Note: This is currently only used by yield*, we still need to support it in
other places (such as for-of loops).  It can be used manually of course.

(This CL does not touch the full-codegen implementation of yield* because that
code is already dead.  The yield* desugaring already supports return and doesn't
need to be touched.)

BUG=v8:3566
LOG=y

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

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

R=littledan@chromium.org
BUG=

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

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

The test currently only shows the JavaScript stack frames, I'll then add
support for interleaved WebAssembly stack frames and update the test.

R=titzer@chromium.org

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

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

(RELAND: the problem before was a missing write barrier for adding the code
entry to the new closure. It's been addressed with a new macro instruction
and test. The only change to this CL is the addition of two calls to
__ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...
Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
And Benedikt reviewed it as well.

TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org

BUG=

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

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

R=neis

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

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

R=mstarzinger@chromium.org, rmcilroy@chromium.org
BUG=v8:4690
LOG=N

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

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

  Unstructured control flow caused by excpetion handling leads to a wrong x87 stack
  state. This patch is to reset the x87 state at the hanlder entry point.

  Thanks for help from weiliang.lin@intel.com.

BUG=

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

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

BUG=

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

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

Synchronize calls in the heap iterator have been put there for the
serializer, which never actually made use of them. This CL fixes that.

R=vogelheim@chromium.org

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

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

This CL deals with yield* by desugaring it in the parser.  Hence the
full-codegen implementation of it becomes obsolete and can be removed in a
future CL.

The only change in semantics should be that the results of the iterator's next
and throw methods are checked to be objects, which didn't happen before but is
required by the spec.

BUG=

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

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

Code compiled during snapshot are overwhelmingly for functions
that are only used for bootstrapping. It makes no sense to
include them in the startup snapshot, which bloats up the snapshot size
and slows down deserialization.

Snapshot sizes for comparison, for ia32:
w/o --ignition:   484k
w/ --ignition:    537k
bytecode removed: 489k

R=rmcilroy@chromium.org,mstarzinger@chromium.org

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

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

This implements proper context switching while unwinding the stack due
to an exception being handled in interpreted code. The context under
which the handler is scoped is being preserved in a dedicated register
while the try-block is running. Both, the stack unwinding machinery as
well as the graph builder, restore the context from that register.

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

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

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

Removes skips for two tests in cctest that are no longer crashing with ignition.

BUG=v8:4680
LOG=N

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

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

BUG=

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

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