Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/2a0adf9..1314c9a

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/80a58af..e650872

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/5bc7c5e..70cd354

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

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

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

Review-Url: https://codereview.chromium.org/2805613003
Cr-Commit-Position: refs/heads/master@{#44462}

R=bmeurer@chromium.org

Review-Url: https://codereview.chromium.org/2803643004
Cr-Commit-Position: refs/heads/master@{#44461}

This patch fixes build error for 64bit platforms introduces in
https://codereview.chromium.org/2793323002
Error message from MIPS64 buildbot: error: implicit conversion loses
integer precision: 'long' to 'int' [-Werror,-Wshorten-64-to-32]

BUG=

Review-Url: https://codereview.chromium.org/2801713004
Cr-Commit-Position: refs/heads/master@{#44460}

Revert of [heap] Remove size specializations in static object visitors. (patchset #4 id:60001 of https://codereview.chromium.org/2763413007/ )

Reason for revert:
Speculative revert due to canary crashes.

BUG=chromium:708339,chromium:707790

Original issue's description:
> [heap] Remove size specializations in static object visitors.
>
> Apart from that this patch adds kVisitJSObjectFast for JSObjects that
> do not have any unboxed double fields and can be visited without
> run-time layout check.
>
> BUG=chromium:694255
>
> Review-Url: https://codereview.chromium.org/2763413007
> Cr-Commit-Position: refs/heads/master@{#44237}
> Committed: https://chromium.googlesource.com/v8/v8/+/dbb1cbe3a85d5c5528ce876d905e78d2ab35f00b

TBR=mlippautz@chromium.org,hpayer@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:694255

Review-Url: https://codereview.chromium.org/2800923004
Cr-Commit-Position: refs/heads/master@{#44459}

This fixes behavior for HeapNumber {index} arguments passed to
AdvanceStringIndex.

Previously, we'd blindly treat {index} as a Smi. Passing a HeapNumber instead
would result in a Smi addition on the tagged HeapNumber pointer.

BUG=chromium:709015

Review-Url: https://codereview.chromium.org/2798933003
Cr-Commit-Position: refs/heads/master@{#44458}

The original CL: https://chromium-review.googlesource.com/c/469610/

R=clemensh@chromium.org

Change-Id: I5ba6aa9964eff63dd19854745aaacee73c071224
Reviewed-on: https://chromium-review.googlesource.com/470206
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44457}

In predictable mode DoSync and DoAsync are only normal
function calls. Therefore I had to do some adjustments
to async compilation to make it work with --predictable:
* I moved all calls to DoSync and DoAsync out of
  DisallowHandleAllocation and DisallowHeapAllocation
  scopes.
* I turned off the use of the semaphore which
  synchronizes the background compilation tasks with
  the main thread. It caused a deadlock.
* Adjust when the AsyncCompileJob is deleted, namely
  after the start function and not after the execution
  of the last compilation task. The reason is that in
  predictable mode all previous tasks are still on the
  stack after the last compilation task.


Bug:

Change-Id: I2f96f64febeee6b8bd5f4da3cec882797d249400
Reviewed-on: https://chromium-review.googlesource.com/469610
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44456}

Review-Url: https://codereview.chromium.org/2806463002
Cr-Commit-Position: refs/heads/master@{#44455}

Bug:

Change-Id: Iddd693d12e55a7a423eb3236006f3c22b41d1f83
Reviewed-on: https://chromium-review.googlesource.com/469829Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44454}

The actual value was always &-ed with 0 so technically correct. ASAN
rightfully complains when allocating an external bitmap though.

BUG=chromium:651354
R=ulan@chromium.org

Review-Url: https://codereview.chromium.org/2799283002
Cr-Commit-Position: refs/heads/master@{#44453}

Why not?

Bug: v8:6215
Change-Id: I29f3731cbd0d03af6858eb475a1df8b8988cb89f
Reviewed-on: https://chromium-review.googlesource.com/469848Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44452}

This CL fixes two more cases in which a regexp could unintentionally transition
to slow mode while on the fast path, leading to possible OOB accesses of
lastIndex.

In both cases, the fix is to re-check the shape and possibly bail to runtime.

BUG=chromium:708247,v8:6210

Review-Url: https://codereview.chromium.org/2803603005
Cr-Commit-Position: refs/heads/master@{#44451}

Review-Url: https://codereview.chromium.org/2799663003
Cr-Commit-Position: refs/heads/master@{#44450}

Drive-by: Fix some getters.

BUG=chromium:651354

Review-Url: https://codereview.chromium.org/2798333002
Cr-Commit-Position: refs/heads/master@{#44449}

This reverts commit 9461fe24.

Reason for revert: Breaks a test in Node.js: 
 parallel/test-util-inspect

=== release test-util-inspect ===                                              
Path: parallel/test-util-inspect
#
# Fatal error in , line 0
# unreachable code
#

==== C stack trace ===============================


Original change's description:
> [builtins] don't inline calls for common Promise ops in async builtins
> 
> InternalResolvePromise, InternalPromiseReject and
> InternalPerformPromiseThen generate quite a lot of code.
> 
> This change adds 3 new TF stubs which inline calls to these builtins.
> These stubs are invoked rather than inlining those operations listed
> above directly. This is done for Async Iteration builtins, as well as
> Async Function builtins. Promise builtins are left as they were, and
> continue to inline these calls.
> 
> This results in a roughly 99kb reduction in snapshot_blob.bin on an x64
> release build.
> 
> BUG=v8:5855
> R=​gsathya@chromium.org, jgruber@chromium.org
> 
> Change-Id: I3349d0f0353a72270ae40b974312d64d1c8a9e46
> Reviewed-on: https://chromium-review.googlesource.com/461269
> Commit-Queue: Caitlin Potter <caitp@igalia.com>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Sathya Gunasekaran (ooo until April 10) <gsathya@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44445}

TBR=mstarzinger@chromium.org,gsathya@chromium.org,caitp@igalia.com,jgruber@chromium.org,v8-reviews@googlegroups.com,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5855

Change-Id: Iabcdf8b025cc9b053a858f8e74389638ac000ba0
Reviewed-on: https://chromium-review.googlesource.com/469946Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44448}

Currently we initialize the allocated buffer to be full of 0s, which
adds significant overhead.

TypedArrayConstructByArrayLike will always either fully initialize the
buffer, or throw an exception, in which case the buffer will not be
leaked to user code.

The length of the new TypedArray (and thus the buffer) is derived from
the length of the source Array/TypedArray, so we know that we will
always set every byte of the new buffer, or throw trying.

Bug:v8:5977

Change-Id: I8ceaa883cfad85f8708a5bdaada3ce463d97e007
Reviewed-on: https://chromium-review.googlesource.com/469348Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44447}

To avoid running infinitely or hitting the stack size limit, bound the
number of steps to execute in the interpreter to 16k.

R=ahaas@chromium.org
BUG=chromium:708457

Change-Id: Ib101bbbc06627641dae2fd1cd1a8d950aa504eaf
Reviewed-on: https://chromium-review.googlesource.com/469609
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44446}

InternalResolvePromise, InternalPromiseReject and
InternalPerformPromiseThen generate quite a lot of code.

This change adds 3 new TF stubs which inline calls to these builtins.
These stubs are invoked rather than inlining those operations listed
above directly. This is done for Async Iteration builtins, as well as
Async Function builtins. Promise builtins are left as they were, and
continue to inline these calls.

This results in a roughly 99kb reduction in snapshot_blob.bin on an x64
release build.

BUG=v8:5855
R=gsathya@chromium.org, jgruber@chromium.org

Change-Id: I3349d0f0353a72270ae40b974312d64d1c8a9e46
Reviewed-on: https://chromium-review.googlesource.com/461269
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Sathya Gunasekaran (ooo until April 10) <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44445}

Doing so will increase the likelyhood of getting the interesting code objects
into the mindump.

Change-Id: I6c6d06bbfe7ab8649139b1146bda0f9b3d679064
Reviewed-on: https://chromium-review.googlesource.com/468967
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44444}

The Run() method ran in chunks of {kRunSteps} steps till completion or
breakpoint, while Step() executed exactly one step.
This CL removes the {kRunSteps} concept, and instead allows to pass the
number of steps to run to the Run() method. Step() just calls Run(1).

R=ahaas@chromium.org
BUG=chromium:708457,v8:5822

Change-Id: I03f7f4da4e0d0e72337399206f1c49ff0f1f041a
Reviewed-on: https://chromium-review.googlesource.com/469846
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44443}

This is used by streams in
https://streams.spec.whatwg.org/commit-snapshots/1375e266b2fe8246bd95cb9d8a49876ba9359dc9/#rs-pipe-through

This also fixes an omission in a6e635d6
that did not properly update the
%OptimizeObjectForAddingMultipleProperties call in prologue.js.

BUG=chromium:668951
R=gsathya@chromium.org,littledan@chromium.org

Review-Url: https://codereview.chromium.org/2796243002
Cr-Commit-Position: refs/heads/master@{#44442}

It's not necessary at finalization, and may be obtained from
the shared, native object.

BUG=

Review-Url: https://codereview.chromium.org/2804863002
Cr-Commit-Position: refs/heads/master@{#44441}

Make Ignition collect BinaryOperationFeedback on ToNumber, using the
shared type feedback slot with the following Inc/Dec bytecode, and use
this feedback in TurboFan to turn the ToNumber(x) operation into a
SpeculativeNumberMultiply(x,1) with the feedback hint.

R=jarin@chromium.org, mstarzinger@chromium.org, rmcilroy@chromium.org
BUG=v8:6214,v8:5267

Review-Url: https://codereview.chromium.org/2804813003
Cr-Commit-Position: refs/heads/master@{#44440}

Bug: v8/6024
Change-Id: Iff8a1b7a75e9f8f18ac24f31a5275e91aa16a272
Reviewed-on: https://chromium-review.googlesource.com/469347
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44439}

Change-Id: Ie84fbc26a3f3782564f3d0734c284f19a75853f3
Reviewed-on: https://chromium-review.googlesource.com/469826Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44438}

Remove the restriction that we cannot reuse code objects generated for
OSR from Ignition to TurboFan.

R=jarin@chromium.org, mstarzinger@chromium.org, rmcilroy@chromium.org
BUG=v8:4764

Review-Url: https://codereview.chromium.org/2798293002
Cr-Commit-Position: refs/heads/master@{#44437}

BUG=v8:5402
R=mstarzinger@chromium.org

Change-Id: I8ce43504fee83dcb6859418a526b2c7aea52e778
Reviewed-on: https://chromium-review.googlesource.com/468968
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44436}

R=ahaas@chromium.org
BUG=v8:6204

Review-Url: https://codereview.chromium.org/2799753003
Cr-Commit-Position: refs/heads/master@{#44435}

The following aspects were changed for the reland:

* The DeferredHandleScope is supposed with a specific pattern,
  i.e. allocate handles in a normal HandleScope and then 
  reopen them in the DeferredHandleScope.
* Set the native_context when it is used in a task.

Change-Id: Ia42c46ec6bc73179cb1f458e36658414ff85cc23
Reviewed-on: https://chromium-review.googlesource.com/468809
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44434}

This CL introduces SloppyArgumentsElements to encapsulate all the constants
for SLOW_ and FAST_SLOPPY_ARGUMENTS_KINDS. This will serve as a better
documentation and reduces the use of undocumented constants.

Change-Id: I7a5b4e79f02573161d8a83aaf6f69fc490883aa5
Reviewed-on: https://chromium-review.googlesource.com/467666Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44433}

Was disabled in the case we use allocation folding, i.e., always...

Sheriffs: This might flush out missed write barriers. In that case: Lets revert
and investigate.

BUG=

Review-Url: https://codereview.chromium.org/2798843004
Cr-Commit-Position: refs/heads/master@{#44432}

Change-Id: I525e29f278c76dbd02cb727d9c70c2d67a47e4c9
Reviewed-on: https://chromium-review.googlesource.com/449676
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44431}

- Add long command names for better first-time experience
- Try to auto-detect the context object on the stack
- Mark free space object ranges
- Add print/p command to evaluate arbitrary python code
- Address expressions can now be arbitrary Python expression with auto
  register substition
- New dso command finds possible HeapObjects on the stack/memory
- New dsa command prints PushStackTraceAndDie message and values

Change-Id: I0f178077f0ccef887aa3fdd2d2d2d732925948ea
NOTRY=true

Change-Id: I0f178077f0ccef887aa3fdd2d2d2d732925948ea
Reviewed-on: https://chromium-review.googlesource.com/468866
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44430}

Revert of [inspector] move console to builtins (patchset #9 id:180001 of https://codereview.chromium.org/2785293002/ )

Reason for revert:
Seems to block roll:
https://codereview.chromium.org/2801013002/

See also:
https://build.chromium.org/p/client.v8.fyi/builders/Linux%20Tests%20%28dbg%29%281%29/builds/2731

Original issue's description:
> [inspector] move console to builtins
>
> What will we get:
> - console would be included into snapshot and allow us to reduce time that we spent in contextCreated function (~5 times faster),
> - it allows us to make further small improvement of console methods, e.g. we can implement super quick return from console.assert if first argument is true,
> - console calls are ~ 15% faster.
>
> BUG=v8:6175
> R=dgozman@chromium.org
>
> Review-Url: https://codereview.chromium.org/2785293002
> Cr-Original-Original-Commit-Position: refs/heads/master@{#44353}
> Committed: https://chromium.googlesource.com/v8/v8/+/55905f85d63d75aaa9313e51eb7bede754a8e41c
> Review-Url: https://codereview.chromium.org/2785293002
> Cr-Original-Commit-Position: refs/heads/master@{#44355}
> Committed: https://chromium.googlesource.com/v8/v8/+/cc74ea0bc4fe4a71fa53d08b62cc18d15e01fbb3
> Review-Url: https://codereview.chromium.org/2785293002
> Cr-Commit-Position: refs/heads/master@{#44416}
> Committed: https://chromium.googlesource.com/v8/v8/+/f5dc738cda0336929dcb8eb73b87fdcd01b7c685

TBR=dgozman@chromium.org,kozyatinskiy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6175

Review-Url: https://codereview.chromium.org/2801023003
Cr-Commit-Position: refs/heads/master@{#44429}

BUG=v8:5437,chromium:708247

Review-Url: https://codereview.chromium.org/2797993002
Cr-Commit-Position: refs/heads/master@{#44428}

Moves the ToName elision out of the peephole optimizer and into the
BytecodeGenerator.

BUG=v8:6194

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

Bug: v8:6154
NOTRY=true
TBR=yangguo@chromium.org

Change-Id: I50529f820107dae701476deee285fa62a59374d1
Reviewed-on: https://chromium-review.googlesource.com/469706Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44426}

Perhaps it would be better to always start the timer, but that
would require some refactoring of tests.

Review-Url: https://codereview.chromium.org/2786493006
Cr-Commit-Position: refs/heads/master@{#44425}

We have a weird performance cliff, where using an object literal for
allocation is way slower than using a constructor function, or starting
from the empty object literal and using transitioning stores. The reason
is that we limit the inlining of JSCreateLiteralObject nodes in TurboFan
to max. 8 fast properties. So as soon as you get above 8, you'll get a
runtime function call to %CreateObjectLiteral, which is a lot slower
than the inlined allocation and initialization. Still not ideal, but
less unpredictable (hopefully).

R=jarin@chromium.org
BUG=v8:6211

Review-Url: https://codereview.chromium.org/2805613002
Cr-Commit-Position: refs/heads/master@{#44424}