This lifts the sqrt(n) limit on number of evacuation candidates,
replaces O(n * sqrt(n)) algorithm with O(n*log(n)) algorithm, and
removes hard-coded constants.

Evacuation candidates are selected as follows:

1) Sort pages from the most free to the least free.

2) Select the first m pages as evacuation candidates such that m is as
large as possible under the two conditions:

- The total size of live objects in the first m pages does not exceed
the given limit. This is based on the assumption that the evacuation cost is
proportional to the total size of moved objects.

- The fragmentation of the (m+1)-th page does not exceed the given
limit.

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

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

And delete remnants of non-vectorized LoadICs from the type feedback oracle

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

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

This simplifies inlining, in that we only need to update uses of Start
and inputs of End instead of walking the whole inlinee to update all
outer frame states.

R=mstarzinger@chromium.org

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

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

R=mstarzinger@chromium.org

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

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

TBR=machenbach@chromium.org
BUG=chromium:470930
LOG=N

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

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

If both inputs to JSStrictEqual/JSStrictNotEqual are unique values (i.e.
values with a canonical representation), we can lower the comparison to
ReferenceEqual instead of StringEqual or CompareIC.

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

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

Rolling v8/third_party/icu to f1ad7f9ba957571dc692ea3e187612c685615e19

Rolling v8/tools/clang to dbc958e1b51949ca815ca31a8f9bf4a760ca1d35

TBR=machenbach@chromium.org

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

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

When we enter a method that needs access to the [[HomeObject]]
we allocate a local variable `.home_object` and assign it the
value from the [[HomeObject]] private symbol. Something along
the lines of:

  method() {
    var .home_object = %ThisFunction()[home_object_symbol];
    ...
  }

BUG=v8:3867, v8:4031
LOG=N

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

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

TBR=jkummerow@chromium.org
NOTRY=true

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

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

These are similar to the Map/Set constructors when called with an array,
except that they are guaranteed to be side-effect free if called with
a packed array.

This will be useful in implementing structured clone which, as
specified in HTML, speaks in terms of the internal [[MapData]]
and [[SetData]] slots without going through the exposed iteration
ES semantics.

BUG=v8:3340
LOG=y

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

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

The April 14 2015 final draft of the ES6 specification states that the
`prototype` property of generator function instances should be writable.

BUG=v8:4140, v8:4140
LOG=N
R=arv@chromium.org

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

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

These return arrays representing the current contents of the given
Map/Set. They are similar to what would be returned by the JS code:

  Array.from(collection)

except that they are guaranteed side-effect free.

This will be useful in implementing structured clone which, as
specified in HTML, speaks in terms of the internal [[MapData]]
and [[SetData]] slots without going through the exposed iteration
ES semantics.

BUG=v8:3340
LOG=y

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

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

On systems that have CLOCK_REALTIME_COARSE with good enough resolution,
we can avoid making a system call to get the current time; it's serviced
from the vDSO.

This is v2 of the patch.  v1 can be found at [0] but was reverted in [1]
because of Chromium sandbox restrictions.  The necessary changes have
been applied upstream in [2].

[0] https://codereview.chromium.org/1125003002
[1] https://codereview.chromium.org/1130083003
[2] https://codereview.chromium.org/1133653002

BUG=
LOG=N

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

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

BUG=chromium:492021
LOG=n

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

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

Only supports constructing new objects and returning size.
Followup patch will need to add ability to retrieve and
set contents in order to support structured clone.

Also removes a bunch of outdated "experimental" markers from v8.h.

BUG=v8:3340
LOG=y

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

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

Port a86384f1

Original commit message:
Also introduce new interface descriptors for the trampoline and full
versions of those stubs.

Currently, the stubs aren't functional.

R=mvstanton@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

TBR=hpayer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

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

Port eca5b5d7

Original commit message:
* Hash code is now just done with a private own symbol instead of the hidden string, which predates symbols.
* In the long run we should do all hidden properties this way and get rid of the
hidden magic 0-length string with the zero hash code.  The advantages include
less complexity and being able to do things from JS in a natural way.
* Initially, the performance of weak set regressed, because it's a little harder
to do the lookup in C++.  Instead of heroics in C++ to make things faster I
moved some functionality into JS and got the performance back. JS is supposed to be good at looking up named properties on objects.
* This also changes hash codes of Smis so that they are always Smis.

Performance figures are in the comments to the code review.  Summary: Most of js-perf-test/Collections is neutral.  Set and Map with object keys are 40-50% better.  WeakMap is -5% and WeakSet is +9%.  After the measurements, I fixed global proxies, which cost 1% on most tests and 5% on the weak ones :-(.

In the code review comments is a patch with an example of the heroics we could do in C++ to make lookup faster (I hope we don't have to do this.  Instead of checking for the property, then doing a new lookup to insert it, we could do one lookup and handle the addition immediately).  With the current benchmarks above this buys us nothing, but if we go back to doing more lookups in C++ instead of in stubs and JS then it's a win.

In a similar vein we could give the magic zero hash code to the hash code
symbol.  Then when we look up the hash code we would sometimes see the table
with all the hidden properties.  This dual use of the field for either the hash
code or the table with all hidden properties and the hash code is rather ugly,
and this CL gets rid of it.  I'd be loath to bring it back.  On the benchmarks quoted above it's slightly slower than moving the hash code lookup to JS like in this CL.

One worry is that the benchmark results above are more monomorphic than real
world code, so may be overstating the performance benefits of moving to JS.  I
think this is part of a general issue we have with handling polymorphic code in
JS and any solutions there will benefit this solution, which boils down to
regular property access. Any improvement there will lift all boats.

R=erikcorry@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

Port 32de6778

Original commit message:
The reason is that this information will be needed to compute the number of
vector ic slots done at numbering time.

R=mvstanton@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

TBR=hpayer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

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

This configures *san in v8 just like in chromium's
common.gypi. I also addresses compilation problems with ICU
and usage of instrumented libc++.

TBR=svenpanne@chromium.org

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

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

TBR=hpayer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

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

Without this change, wildcards always overwrite the outcomes
of more specific rules. Now we always merge.

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

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

R=ulan@chromium.org
BUG=chromium:491943
LOG=Y

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

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

BUG=
NOTRY=true

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

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

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

This way we don't need to connect (potentially) non-terminating loops
later during control reduction, which saves one forward pass over the
control graph.  Long term we will move the trimming functionality of
the control reducer to the GraphReducer, and get rid of the Finish
method again.

As a bonus, this change also properly rewires Terminate, Throw and
Deoptimize during inlining.

R=mstarzinger@chromium.org

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

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

R=bmeurer@chromium.org

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

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

BUG=chromium:492021
LOG=n

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

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

* Hash code is now just done with a private own symbol instead of the hidden string, which predates symbols.
* In the long run we should do all hidden properties this way and get rid of the
hidden magic 0-length string with the zero hash code.  The advantages include
less complexity and being able to do things from JS in a natural way.
* Initially, the performance of weak set regressed, because it's a little harder
to do the lookup in C++.  Instead of heroics in C++ to make things faster I
moved some functionality into JS and got the performance back. JS is supposed to be good at looking up named properties on objects.
* This also changes hash codes of Smis so that they are always Smis.

Performance figures are in the comments to the code review.  Summary: Most of js-perf-test/Collections is neutral.  Set and Map with object keys are 40-50% better.  WeakMap is -5% and WeakSet is +9%.  After the measurements, I fixed global proxies, which cost 1% on most tests and 5% on the weak ones :-(.

In the code review comments is a patch with an example of the heroics we could do in C++ to make lookup faster (I hope we don't have to do this.  Instead of checking for the property, then doing a new lookup to insert it, we could do one lookup and handle the addition immediately).  With the current benchmarks above this buys us nothing, but if we go back to doing more lookups in C++ instead of in stubs and JS then it's a win.

In a similar vein we could give the magic zero hash code to the hash code
symbol.  Then when we look up the hash code we would sometimes see the table
with all the hidden properties.  This dual use of the field for either the hash
code or the table with all hidden properties and the hash code is rather ugly,
and this CL gets rid of it.  I'd be loath to bring it back.  On the benchmarks quoted above it's slightly slower than moving the hash code lookup to JS like in this CL.

One worry is that the benchmark results above are more monomorphic than real
world code, so may be overstating the performance benefits of moving to JS.  I
think this is part of a general issue we have with handling polymorphic code in
JS and any solutions there will benefit this solution, which boils down to
regular property access. Any improvement there will lift all boats.

R=adamk@chromium.org, verwaest@chromium.org
BUG=

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

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

BUG=chromium:491578
LOG=n
R=jarin@chromium.org

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

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

This simplifies the handling of the End node. Based on this CL we will
finally fix terminating every loop from the beginning (via Terminate
nodes) and fix inlining of Throw, Deoptimize and Terminate.

R=mstarzinger@chromium.org

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

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

Revert of Fixed a couple of failing DCHECK(has_pending_exception()). (patchset #1 id:1 of https://codereview.chromium.org/1151373002/)

Reason for revert:
Broke V8 Linux - nosnap.

Original issue's description:
> Fixed a couple of failing DCHECK(has_pending_exception()).
>
> BUG=chromium:491062
> LOG=N
>
> Committed: https://crrev.com/62b56507cce3c57a2e1aebce6d34f29b3b64e762
> Cr-Commit-Position: refs/heads/master@{#28617}

TBR=yangguo@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:491062

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

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

BUG=

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

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

BUG=chromium:491062
LOG=N

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

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

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

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

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

The reason is that this information will be needed to compute the number of
vector ic slots done at numbering time.

BUG=

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

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

BUG=chromium:491481
R=mstarzinger@chromium.org
LOG=n

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

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

This fixes a corner-case where deoptimization while evaluating the
value to a __proto__ property after computed property names appeared
in an object literal, lead to environments not being in sync with
unoptimized code.

R=arv@chromium.org
TEST=mjsunit/harmony/computed-property-names-deopt

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

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

R=mstarzinger@chromium.org

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

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