[api] Make ObjectTemplate::SetNativeDataProperty() work even if the ObjectTemplate does not have a constructor.

Previously ObjectTemplate::New() logic relied on the fact that all the accessor properties are already installed in the initial map of the function object of the constructor FunctionTemplate.
When the FunctionTemplate were instantiated the accessors of the instance templates from the whole inheritance chain were accumulated and added to the initial map.
ObjectTemplate::SetSetAccessor() used to explicitly ensure that the ObjectTemplate has a constructor and therefore an initial map to add all accessors to.

The new approach is to add all the accessors and data properties to the object exactly when the ObjectTemplate is instantiated. In order to keep it fast we now cache the object boilerplates in the Isolate::template_instantiations_cache (the former function_cache), so the object creation turns to be a deep copying of the boilerplate object.

BUG=chromium:579009
LOG=Y

Committed: https://crrev.com/6a118774244d087b5979e9291d628a994f21d59d
Cr-Commit-Position: refs/heads/master@{#33674}

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

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

BUG=

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

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

BUG=

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

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

Rolling v8/tools/clang to f0dada1961030974d4da5591b1fef8cf42bded15

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

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

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

  port 334d1794 (r33780)

  original commit message:
  This change should unify handling of finally blocks in Turbofan's
  AstGraphBuilder and in full-code. This should enable smooth deoptimization
  from finally blocks.

BUG=

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

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

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/1675903002

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

Port 334d1794

Original commit message:

    This change should unify handling of finally blocks in Turbofan's
    AstGraphBuilder and in full-code. This should enable smooth deoptimization
    from finally blocks.

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

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

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

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

BUG=
TEST=cctest/test-assembler-mips/min_max, cctest/test-assembler-mips/mina_maxa, cctest/test-assembler-mips64/min_max, cctest/test-assembler-mips64/mina_maxa

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

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

We assume split-edge form throughout the register allocation pipeline,
so added validation in isel.

BUG=

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

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

The call can be used by the embedder to provide information on the workers
executing background tasks.

BUG=chromium:524425
LOG=N

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

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

Revert of [es7] refactor and fix Object.values() / Object.entries() (patchset #6 id:100001 of https://codereview.chromium.org/1637753004/ )

Reason for revert:
[Sheriff] Breaks gc stress:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/1642

Original issue's description:
> [es7] refactor and fix Object.values() / Object.entries()
>
> Previously, Object.values() and Object.entries() were piggy-backing on
> Object.keys(). This meant that they would pre-filter non-enumerable properties,
> violating the runtime behaviour of the methods. Unfortunately, this does not
> match the current proposal text.
>
> Also incorporates several tests verifying this behaviour based on tests included
> in the ChakraCore implementation.
>
> BUG=v8:4663
> LOG=N
> R=adamk@chromium.org, rossberg@chromium.org, littledan@chromium.org
>
> Committed: https://crrev.com/5c5ccd9d7f8693990d1a9eb26ba3a94f376dcf0b
> Cr-Commit-Position: refs/heads/master@{#33782}

TBR=littledan@chromium.org,adamk@chromium.org,cbruni@chromium.org,rossberg@chromium.org,caitpotter88@gmail.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4663

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

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

R=jarin@chromium.org

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

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

BUG=v8:4280
LOG=N

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

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

Before:

REX.W cmpq r9,r8
setzl r8l
movzxbl r8,r8
REX.W cmpq r8,0x0
jz 185

After:

REX.W cmpq r9,r8
jnz 149

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

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

To avoid returning a signaling NaN the result is multiplied by 1.0.

R=titzer@chromium.org, binji@chromium.org

BUG=4733
LOG=Y

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

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

Previously, Object.values() and Object.entries() were piggy-backing on
Object.keys(). This meant that they would pre-filter non-enumerable properties,
violating the runtime behaviour of the methods. Unfortunately, this does not
match the current proposal text.

Also incorporates several tests verifying this behaviour based on tests included
in the ChakraCore implementation.

BUG=v8:4663
LOG=N
R=adamk@chromium.org, rossberg@chromium.org, littledan@chromium.org

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

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

This makes the dispatch table similar to the builtins code list and makes
sure that the dispatch table does not move.

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

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

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

This change should unify handling of finally blocks in Turbofan's
AstGraphBuilder and in full-code. This should enable smooth deoptimization
from finally blocks.

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

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

This makes the field in question more generic by renaming it from the
previous "depth" to "data". Pure refactoring, no function change.

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

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

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

The CL 33579 (https://codereview.chromium.org/1618343002) use code offsets instead of raw PC where possible.

But the offset maybe come from an optimized frame, not the un-optimized frame that FromCodeOffset and BreakIndexFromCodeOffset function expect.
So The offset from optimized frame can't be used in FromCodeOffset and  BreakIndexFromCodeOffset function.

This CL use the frame summary to find the corresponding code offset in unoptimized code according to Yang's suggestion.

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

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

Trying to sort a string should throw a TypeError, proper handling
of elements just needs to get out of the way.

BUG=chromium:584188
LOG=n
R=cbruni@chromium.org

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

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

To bring V8 into line with the proposed design changes in:

 https://github.com/WebAssembly/design/pull/489

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

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

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

R=mstarzinger@chromium.org

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

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

- drilldown lazy and recursive
- improve parsing

NOTRY=true

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

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

The implementation of Object.getOwnPropertyDescriptor always called into
C++ anyway, so there's no need to have this JavaScript wrapper around at
all.

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

Committed: https://crrev.com/3fdd37b028f4711d0f6dcb038f575ce08ef0cfa3
Cr-Commit-Position: refs/heads/master@{#33379}

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

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

NOTRY=true
TBR=machenbach@chromium.org

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

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

R=verwaest@chromium.org
BUG=none
LOG=n

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

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

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}