R=machenbach@chromium.org

Bug: v8:7335
Change-Id: I8a97d67be6888014d015ec3f0ec486a3c3d9861a
Reviewed-on: https://chromium-review.googlesource.com/889756Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50945}

Bug: v8:7335
Change-Id: I6610bba00ff558de5826934c326fc2873c91a1a3
Reviewed-on: https://chromium-review.googlesource.com/890742Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50944}

This only affects document.all, which is the only user of
|ObjectTemplate::SetCallAsFunctionHandler|, and will mean that
new document.all() will throw TypeError. There are tests for this:
//src/third_party/WebKit/LayoutTests/external/wpt/html/infrastructure/common-dom-interfaces/collections/htmlallcollection.html

(cherry picked from commit 7233447e4ac4587c81e91077857f8a30c4a6d2df)

Change-Id: Ibb39b3c61b688591c781158cf4abc0c2d74c908e
Reviewed-on: https://chromium-review.googlesource.com/882642Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Philip Jägenstedt <foolip@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/890496
Cr-Commit-Position: refs/heads/master@{#50943}

Add inbounds benchmark for String.p.charCodeAt
and add in and out of bounds benchmarks for
String.p.codePointAt.

Bug: v8:7092, v8:7326, chromium:806758
Change-Id: I48065627bd79d8fb24e55b2f6dce590e7adbbd6e
Reviewed-on: https://chromium-review.googlesource.com/891858Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50942}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/8bf670e..f8323d8

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/82f653f..69f2184

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/1243a6d..a312f49

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

Change-Id: Ic07d910e6fee31c8bff82b47662edd2bd0907a58
Reviewed-on: https://chromium-review.googlesource.com/892618
Commit-Queue: v8 autoroll <v8-autoroll@chromium.org>
Reviewed-by: v8 autoroll <v8-autoroll@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50941}

I8x16Shl/I8x16ShrS/I8x16ShrU,I8x16Mul

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

Bug: 
Change-Id: I97d7f077c26fe6f8be6464582f20d4e3c8fd4667
Reviewed-on: https://chromium-review.googlesource.com/853772
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50940}

This is a v8-port of
https://chromium-review.googlesource.com/c/chromium/src/+/890176 .

By default, ICU tries to load data items (e.g. brkitr/char.brk)
from individual files before trying the common data. Because
all the ICU data Chrome needs is included in the common ICU data file
that is memory mapped in InitializeICU(), trying to load from the
disk just wastes cycles because there's no file with separate ICU data
items.

Bug: chromium:805694
Test: Intl tests
Change-Id: Ia7e77d658b56d98027336acd2c91fd5f7b2cea3e
Reviewed-on: https://chromium-review.googlesource.com/890343Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50939}

This is a reland of 7dbfec50, now that
pdfium has been updated to avoid libfuzzer build failures. I've tested
this change locally in pdfium xfa and non-xfa builds.

The calls in chromium were removed in https://crrev.com/c/865160,
while pdfium was updated in https://pdfium-review.googlesource.com/c/pdfium/+/23270.

Bug: v8:7269, v8:7273, v8:7274
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I2d49033fcb305eeba87cca1e27840f278220d15e
Reviewed-on: https://chromium-review.googlesource.com/890051Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50938}

TBR=sergiyb@chromium.org

Bug: v8:6917
Change-Id: I6d526410520fe7b2cfeff536ed260b37dbb2b8b6
Reviewed-on: https://chromium-review.googlesource.com/891819Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50937}

The stock GCC on Ubuntu 16.04 complains these constants
are unused (possibly gcc issue). This CL changes these
to constexpr to workaround gcc errors.

R=clemensh@chromium.org, joransiu@ca.ibm.com

Change-Id: I8c1772e91744bc46ace6bee576b90d40c0cdf41f
Reviewed-on: https://chromium-review.googlesource.com/881554Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#50936}

Things that don't work yet:
(a) pre parsed scope data is broken
(b) private fields can be accessed outside classes
(c) no early or runtime error for accessing unknown fields

Things that do work:
everything else

Change-Id: I3d58be44e2be73ec50defb42403112a8a5e68c54
Bug: v8:5368
Reviewed-on: https://chromium-review.googlesource.com/865497
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50935}

This adjusts the RunMicrotask logic to invoke CallHandlerInfo microtasks
from CSA land directly (via a runtime function call), instead of bailing
out to C++ for the rest of the microtask queue entries. Even in simple
micro-benchmarks there doesn't seem to be a huge performance difference.
In fact performance get's better when CallHandlerInfo and promises are
mixed, which makes sense, since calling from C++ to JS land is more
expensive than the other way around.

But just in case the runtime function call overhead ever becomes the
bottleneck we can introduce a direct C++ call and setup a handle scope
around it, much like a very simple version of CallApiFunctionStub.

This greatly simplifies the microtask handling and paves the way for
refactoring the queue to significant reduce the GC overhead associated
with promises currently.

Bug: v8:7253
Change-Id: I33adb62a6bada138674d324f36d4be894e27f3c9
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/890441Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50934}

The @@species protector guards the following (in case of Promises):

  - The initial Promise.prototype has the initial "constructor"
    pointing to the Promise constructor.
  - No JSPromise instance has a "constructor" property.

So this is sufficient to guard the fast-path in PromiseResolve, given
that we check whether the value is actually a JSPromise and that the
[[Prototype]] of value is the (initial) Promise.prototype.

Also refactor the code a bit and avoid the BranchIfSameValue, which
blows up the builtin quite a lot, since we already know that constructor
must be a valid JSReceiver and thus we can simply use WordEqual to
compare value's "constructor" to the constructor.

Bug: v8:7253
Change-Id: I6413882241c9648c95bb2299100a6c3a7c803110
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/890438Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50933}

We were starting an allocation step during NewSpace::AddFreshPage. At
this point, we had advanced the page, but not updated allocation_info_.
This ultimately led to assertions as Space::Size was not expecting
to be called when to_space_.page_{high,low} are inconsistent with
allocation_info_.top().

The solution here is to avoid starting the step in the middle of the
space state mutation. We account for memory allocated so far before the
mutation is started, and then start a new step after the mutation has
been completed.

Bug: chromium:806179
Change-Id: I17ee896d80c4ec752baa2b17c3fd2bef7ea2ca33
Reviewed-on: https://chromium-review.googlesource.com/889981Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Cr-Commit-Position: refs/heads/master@{#50932}

Even though most compilers accept the method to be private, gcc 4.8
complains about this (which seems to be correct). Thus we make this
method protected.

R=franzih@chromium.org

Change-Id: Ia49b2ddebe1ced7529d4943107a76a909c355b73
Reviewed-on: https://chromium-review.googlesource.com/890449Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50931}

TBR=sergiyb@chromium.org
NOTRY=true

Bug: v8:7012
Change-Id: I9d2a8b4b01f7f682490e9f784c05df4c9eeb8557
Reviewed-on: https://chromium-review.googlesource.com/891324
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50930}

This adds back an option for interrupt budget available in no-snap
builds. This also adds a fuzzer configuration for numfuzz that enables
fuzzing the interrupt budget option. A new flag --disable-analysis
allows to generally skip the fuzzer's analysis phase, which can be
chosen for interrupt budget, which doesn't support an analysis phase.

Bug: v8:6917
Change-Id: I546dd9ee41c3e0fb027108ef4606a34514f230d4
Reviewed-on: https://chromium-review.googlesource.com/885805Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50929}

This reverts commit 8a27c7d3.

Reason for revert: 

Having more tasks then work items is intentional in some use cases, i.e. Scavenging where RunInParallel() does parallel processing on a dynamic workload *after* the initial set of work items:

    {
      barrier_->Start();
      TimedScope scope(&scavenging_time);
      PageScavengingItem* item = nullptr;
      while ((item = GetItem<PageScavengingItem>()) != nullptr) {
        item->Process(scavenger_);
        item->MarkFinished();
      }
      do {
        scavenger_->Process(barrier_);
      } while (!barrier_->Wait());
      scavenger_->Process();
    }

Original change's description:
> v8::ItemParallelJob : Do not launch more Tasks than there are Items to process.
> 
> Except when there are 0 items. For some reason I don't quite understand yet, not
> calling Run() on tasks_[0] when there are 0 items results in DCHECKs...
> 
> Bug: chromium:806237
> Change-Id: I38c8fffde64a42f93f4efda492832651137eebd7
> Reviewed-on: https://chromium-review.googlesource.com/888704
> Commit-Queue: Gabriel Charette <gab@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50924}

TBR=gab@chromium.org,mlippautz@chromium.org

Change-Id: Iad2ab16bb41f339de8e3fbca1c08c5d26b8a0111
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:806237
Reviewed-on: https://chromium-review.googlesource.com/891186Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50928}

This is the first step for retiring swarming tests with gyp.

TBR=sergiyb@chromium.org
NOTRY=true

Bug: v8:7335
Change-Id: I98145843b91d47a77e06173c2a421fcc0d4e5586
Reviewed-on: https://chromium-review.googlesource.com/891230
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50927}

R=tebbi@chromium.org

Change-Id: Iae9a3774eb7913388350ce3cd0a96d6a6cca25e8
Reviewed-on: https://chromium-review.googlesource.com/885845Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50926}

BUG=chromium:798964

Change-Id: I63c373ef3f27a3295fc79f5c82d78b5fd89a83da
Reviewed-on: https://chromium-review.googlesource.com/888752
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50925}

Except when there are 0 items. For some reason I don't quite understand yet, not
calling Run() on tasks_[0] when there are 0 items results in DCHECKs...

Bug: chromium:806237
Change-Id: I38c8fffde64a42f93f4efda492832651137eebd7
Reviewed-on: https://chromium-review.googlesource.com/888704
Commit-Queue: Gabriel Charette <gab@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50924}

Wide suspends have a "wide" (or "extra-wide") bytecode at their offset,
rather than the suspend itself, so they were failing the return check.

Bug: chromium:805765
Change-Id: Iabfc2a2167d09eda2f6885d9100287aadcd8fee9
Reviewed-on: https://chromium-review.googlesource.com/887082Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50923}

Bug: chromium:806200
Change-Id: If76a8cb5b988321d38d170dfba7c1fc5354e2667
Reviewed-on: https://chromium-review.googlesource.com/888922Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50922}

There is currently no test that shows this bug (it was found as part of the DSL
experiment), but it should get fixed anyway and it will eventually be verified
by the A.p.splice CSA builtin port that is in progress.

Change-Id: I9b6da8dc8f3151ad0b0a06c3ca10d604060efef7
Reviewed-on: https://chromium-review.googlesource.com/890580Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50921}

This makes the ArrayBuiltinsAssembler consistent with the StringBuiltinsAssembler
and paves the way for tools that expect the assemblers to have a common structure.

Change-Id: I7470fc2cf144f9cc2fdbcee99b31daed267550be
Reviewed-on: https://chromium-review.googlesource.com/889933Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50920}

Bug: v8:5267
Change-Id: I649554733fdbd00c8e82b09aca35b0ff1f823560
Reviewed-on: https://chromium-review.googlesource.com/890262Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50919}

R=machenbach@chromium.org

Bug: v8:7335
Change-Id: Ic89f9cd1fd45ece80da24c85559ef04bee93ee64
Reviewed-on: https://chromium-review.googlesource.com/888699
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50918}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/4ab66b7..8bf670e

Rolling v8/buildtools: https://chromium.googlesource.com/chromium/buildtools/+log/437a616..f115f47

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/8d63750..82f653f

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

Change-Id: Ia2422b93bffa423b4452037ecc27b1f69c14a764
Reviewed-on: https://chromium-review.googlesource.com/890367Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: v8 autoroll <v8-autoroll@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50917}

TBR=sergiyb@chromium.org
NOTRY=true

Bug: chromium:786303
Change-Id: Ia88c6c6e69f7c96dc1ac6d4b4ab140a06711f0f1
Reviewed-on: https://chromium-review.googlesource.com/890520
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50916}

Without realm-eval, the toplevel references in loaded tests are not
garbage-collected and changes in the tests can affect the global
object.

TBR=ulan@chromium.org
NOTRY=true

Bug: v8:7379, v8:7376
Change-Id: Id4d451e38fe49c6531a07d541ad3c67298b6acf2
Reviewed-on: https://chromium-review.googlesource.com/890519
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50915}

Bug: chromium:801602
Test: intl/date-format/month-far-future.js
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ie2279680e8879c943cbf0873a933d2633e759212
Reviewed-on: https://chromium-review.googlesource.com/868376Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50914}

import() is shipping by default in Chrome 63 and import.meta is
shipping in Chrome 64 already.

The flag still exists so that embedders can turn off the feature
if required.

Bug: v8:5785, v8:6693
Change-Id: Ie6c8f90927958022900f677ea5a771527111aece
Reviewed-on: https://chromium-review.googlesource.com/889658
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50913}

This reverts commit 4dcf68e9.

Reason for revert: Bug should be fixed.

Original change's description:
> [test] Skip tests failing on gc fuzzer
> 
> Temporarily skipping tests until a fix has landed.
> 
> TBR=ofrobots@google.com
> NOTRY=true
> 
> Bug: v8:7313
> Change-Id: I9d55f1ba190ee8104b90fd80c4b1de05508475e5
> Reviewed-on: https://chromium-review.googlesource.com/888642
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50900}

TBR=machenbach@chromium.org,ofrobots@google.com,majeski@google.com

Change-Id: I9ac4800331f572e23c24d936f8b6c51884beeacb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7313
Reviewed-on: https://chromium-review.googlesource.com/888563Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50912}

Bug: v8:7369
Change-Id: I35b69295a4f9ffab0d5d0501f2f0252dee1a48a3
Reviewed-on: https://chromium-review.googlesource.com/887428
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50911}

These assertions would have caught the bug closer to the source.

BUG=v8:7313

Change-Id: I19b75c3fc7bff8216dda370114ff00326f128116
Reviewed-on: https://chromium-review.googlesource.com/887175Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Cr-Commit-Position: refs/heads/master@{#50910}

Don't start new steps recursively if a step is already in progress.
Having this property on a space is not sufficient, as an allocation
is a global (heap-wide) event. Computing the next step size, for example
is a property of all observers in existence rather than the spaces in
existence.

In this case a failure was due to the fact that we attempted to compute
the next step size while a given observer was mid-way through its step
triggered from a different space. bytes_to_next_step_ was partially
updated at that point.

BUG=v8:7313

Change-Id: Iaf632fce2cfd5ed49b0f41a69c3694e505e17d81
Reviewed-on: https://chromium-review.googlesource.com/887174
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50909}

Tbr: ulan@chromium.org
No-try: true
Bug: v8:7266
Change-Id: Ia0965fa085d8d92b65a9353174e123337dc1ef6b
Reviewed-on: https://chromium-review.googlesource.com/888585Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50908}

This ensures that i32 values which are loaded into 64 bit registers
have the upper 32 bits cleared.

R=titzer@chromium.org

Bug: v8:6600
Change-Id: I5eb2b65ac079b5683c83d755b1aa4a626411d5d4
Reviewed-on: https://chromium-review.googlesource.com/888702Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50907}

Use a sequence of move instructions instead.

Bug: 
Change-Id: I63a45ce7baaa9ebcba0d3e86910839e2ddedecd5
Reviewed-on: https://chromium-review.googlesource.com/888561Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#50906}