This CL also removes the v8::internal::wasm::testing namespace, which
had methods that were defined in wasm-module.h, moving them to be
*ForTesting methods on the corresponding WASM heap objects.

R=clemensh@chromium.org

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

Bug: v8:6644
Change-Id: I5cd713465563f2dc803b175684bf04a05559e653
Reviewed-on: https://chromium-review.googlesource.com/693239
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48285}

This CL addresses a couple of minor issues that were in the way of
properly inlining polymorphic constructors calls, i.e. as found in
this common pattern using Symbol.species:

  class A {
    static get [Symbol.species]() { return this; }
    clone() { return new this.constructor[Symbol.species](); }
  }
  class B extends A {
    static get [Symbol.species]() { return this; }
  }

  function foo(o) { return o.clone(); }
  foo(new A());
  foo(new B());

Here the call to this.constructor[Symbol.species]() is the interesting
site. To get this fully inlined, we had to

  - make sure we don't introduce too many CheckHeapObject eagerly that
    block later optimizations (instead we try harder to see whether the
    receiver is already provably a HeapObject), and
  - also update the new.target of polymorphic JSConstruct nodes, when
    it refers to the same node as the target that we're specializing
    to (this way the JSCreate becomes fully inlinable later).

This seems to yield a solid 1.5% on the ARES6 ML benchmark (run via the
d8 cli runner), which confirms the previous profiled estimation. On the
micro-benchmark that specifically measures this feature in isolation we
go from

  testClone: 828 ms.

on V8 ToT as of today and

  testClone: 1439 ms.

on V8 6.1 to

  testClone: 219 ms.

which is a 3.7x improvement, on top of the previous ~2x boost that we
got from inlining the polymorphic symbol lookup.

Bug: v8:6885, v8:6278, v8:6344
Change-Id: Ida7abf683c7879978f181ba7f52a125f4f83ae6f
Reviewed-on: https://chromium-review.googlesource.com/700596Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48284}

This CL speeds up a common pattern found in the React framework:

function f(a, b, c) { ... };
let f_bound = f.bind(this, 1);
let f_bound2 = f_bound(this, 2);

This CL yields roughly a 15x improvement for rebinding a bound function.

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

This ports:
https://chromium-review.googlesource.com/c/chromium/src/+/696886

Bug: chromium:692940, chromium:524758
Change-Id: I158d996ff76c354b8a672b085d476e9687205034
Reviewed-on: https://chromium-review.googlesource.com/700455Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48282}

Reuse existing concurrent marking infrastructure for marking in the
atomic pause.

Details:
- Do not stop concurrent marking when entering the atomic pause.
- Start concurrent marking when it was off. This is required for
  non-incremental MC GCs.
- Use atomic marking state in MC.
- Transition through grey and avoid white->black.

CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux64_tsan_rel;master.tryserver.v8:v8_linux64_tsan_concurrent_marking_rel_ng;master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel

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

Add instruction cache flish for wrapper table in module compiler
instance builder. This fixes several failures in mjsunit/wasm
and mjsunit/asm test suites on some MIPS boards.

Bug: 
Change-Id: Ia8b640ad73a078d29f458d55663606dbbe8e387c
Reviewed-on: https://chromium-review.googlesource.com/697807Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#48280}

Good thing this class is actually being unused. Vector<T> is iterable,
so it should just be iterated using a foreach loop.

R=mstarzinger@chromium.org

Change-Id: Ieb6729e5b1336888989d5ec6128b0782b158b1f7
Reviewed-on: https://chromium-review.googlesource.com/695525Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48279}

Port for: https://chromium-review.googlesource.com/c/v8/v8/+/608975

In code generator for MIPS32, certain instructions are substituted with
corresponding macro-instructions.

TEST=
BUG=

Change-Id: I2ac47a785f0ea14c448f727da124dc78ea6c81af
Reviewed-on: https://chromium-review.googlesource.com/699998Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#48278}

Change-Id: Id34d21437b3881d829526b89058f26741bee7acc
Reviewed-on: https://chromium-review.googlesource.com/695327Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48277}

After closer investigation, the crashes / regressions we currently have are not
so bad that we couldn't have the flag on.

BUG=v8:5516

Change-Id: I1b70cf99de1707d659b2e0abcd3678ec71a530bf
Reviewed-on: https://chromium-review.googlesource.com/699997Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48276}

The Object.is builtin provides an entry point to the abstract operation
SameValue, which properly distinguishes -0 and 0, and also identifies
NaNs. Most of the time you don't need these, but rather just regular
strict equality, but when you do, Object.is(o, -0) is the most readable
way to check for minus zero.

This is for example used in Node.js by formatNumber to properly print -0
for negative zero. However since the builtin thus far implemented as C++
builtin and TurboFan didn't know anything about it, Node.js considering
to go with a more performant, less readable version (which also makes
assumptions about the input value) in

  https://github.com/nodejs/node/pull/15726

until the performance of Object.is will be on par (so hopefully we can
go back to Object.is in Node 9).

This CL ports the baseline implementation of Object.is to CSA, which
is pretty straight-forward since SameValue is already available in
CodeStubAssembler, and inlines a few interesting cases into TurboFan,
i.e. comparing same SSA node, and checking for -0 and NaN explicitly.

On the micro-benchmarks we go from

  testNumberIsMinusZero: 1000 ms.
  testObjectIsMinusZero: 929 ms.
  testObjectIsNaN: 954 ms.
  testObjectIsSame: 793 ms.
  testStrictEqualSame: 104 ms.

to

  testNumberIsMinusZero: 89 ms.
  testObjectIsMinusZero: 88 ms.
  testObjectIsNaN: 88 ms.
  testObjectIsSame: 86 ms.
  testStrictEqualSame: 105 ms.

which is a nice 10x to 11x improvement and brings Object.is on par with
strict equality for most cases.

Drive-by-fix: Also refactor and optimize the SameValue check in the
CodeStubAssembler to avoid code bloat (by not inlining StrictEqual
into every user of SameValue, and also avoiding useless checks).

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

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/05cc4b1..7311b74

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/3f41f93..672cabd

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

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

When atomic operations are used in loops, return the correct opcode length
for loop assignment.

Bug=v8:6842,v8:6532

Change-Id: I306db704d8a0baa5d98c05702360e6dfae11cbfa
Reviewed-on: https://chromium-review.googlesource.com/699561Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48273}

For an improved debugging experience.

Bug: v8:6791
Change-Id: Id4f7fea47036e4520e7b24edf34f210b664672bc
Reviewed-on: https://chromium-review.googlesource.com/699427Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48272}

Original Commit Message:
  In the test-run-wasm and test-run-wasm-64 cctests it is not possible to
  call runtime functions. To test traps in these cctests we therefore
  replace the runtime call with a call to a c-callback, followed by a
  return. This CL fixes the problem that the return did not clean up stack
  parameters.

R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: Ia6b95141341635b769acf12b82b4524a56b12b94
Reviewed-on: https://chromium-review.googlesource.com/698424Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#48271}

I'd like to make sure changes to microtask handling do not break debugging.

R=jarin@chromium.org

Change-Id: I983bd3340261e472b22b0d5b6cded60b64b19d38
Reviewed-on: https://chromium-review.googlesource.com/691715Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48270}

Change-Id: I0de0ea0798c39831765bb3c00a00d0df7471bc3b
Reviewed-on: https://chromium-review.googlesource.com/695407Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48269}

THe change in https://chromium-review.googlesource.com/695108 flushed
out an issue with the IC::UpdatePolymorphicIC logic, where we'd try to
stay MONOMORPHIC or POLYMORPHIC as long as the internalized name doesn't
change. But the calling code already does the internalization for keyed
accesses with Strings, so we need to double check that the same
combination of (map, handler) is not already in the list, and properly
go to MEGAMORPHIC state if there's such a pair already.

This seriously tanked the six-speed-object-literals-ext-es5.js benchmark
on AWFY.

Bug: v8:6367, v8:6278, v8:6344
Change-Id: I90ea88d1fe61c165990c0a10d4a8687ffe351986
Reviewed-on: https://chromium-review.googlesource.com/695307Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48268}

Avoid F5 symbol clash.

Bug: chromium:770684
Change-Id: I9e851c1fe5abbdc4d032b7efdd0462c96d0c8ef3
Reviewed-on: https://chromium-review.googlesource.com/696063Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@vewd.com>
Cr-Commit-Position: refs/heads/master@{#48267}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/ce6d3d8..05cc4b1

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/8ec7b14..3f41f93

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

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

In V8Debugger code we don't expect task_id == null, e.g.
asyncTaskStartedForStepping will trigger debug break on null as task_id.
Let's filter task_id == null out.

This issue is originally filed in Node.js:
https://github.com/nodejs/node/issues/15464

R=dgozman@chromium.org

Bug: none
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Icc9f96105b3c91ee1b102d545a7817f7ee93394c
Reviewed-on: https://chromium-review.googlesource.com/695808Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48265}

This makes sure that helper methods on the {TranslatedState} class stick
to the counting scheme used by {OptimizedFrame::Summarize} within the
stack-walker. Both now treat {kJavaScriptBuiltinContinuation} as real
JavaScript frames.

R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-770543
BUG=chromium:770543

Change-Id: Icda65a7efb487470d39ebf648767a488ebf2e5f1
Reviewed-on: https://chromium-review.googlesource.com/695123
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48264}

R=jarin@chromium.org

Change-Id: I6f2e70d231d2c28c77bee121e98317f3f506fce4
Reviewed-on: https://chromium-review.googlesource.com/691975
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48263}

This makes sure the deoptimizer properly materializes heap objects, even
when the top-most frame happens to be a stub-frame. Without this step
the {arguments_marker} would leak into user-land and most likely be
treated as an undefined value.

R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-769852
BUG=chromium:769852

Change-Id: I4ba17501c5d7e68d1f402b7c2cc5ccb0fb7bfb05
Reviewed-on: https://chromium-review.googlesource.com/691996Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48262}

Until now keyed accesses to properties with string or symbol keys were
only optimized properly while the IC was monomorphic and would go
megamorphic as soon as there's another receiver map, even if the name
was still the same (i.e. the same symbol or internalized string). This
was a weird performance-cliff, that'll hurt modern code especially
because for symbols you can only access them via keyed loads and stores.

This CL fixes the state machine inside the ICs to properly transition to
POLYMORPHIC state (and stay there) as long as the new name matches the
previously recorded name. The FeedbackVector and TurboFan were already
able to deal with this and didn't need any updates.

On the micro-benchmark from the tracking bug we go from

  testStringMonomorphic: 429 ms.
  testSymbolMonomorphic: 431 ms.
  testStringPolymorphic: 429 ms.
  testSymbolPolymorphic: 5621 ms.

to

  testStringMonomorphic: 429 ms.
  testSymbolMonomorphic: 429 ms.
  testStringPolymorphic: 429 ms.
  testSymbolPolymorphic: 430 ms.

effectively eliminating the overhead for symbols completely, and
yielding a 13.5x performance boost.

This also seems to yield a 1% improvement on the ARES6 ML benchmark,
because it eliminates the KEYED_LOAD_ICs for the Symbol.species lookups.

Bug: v8:6367, v8:6278, v8:6344
Change-Id: I879fe56387b4c56203c1ad8ef8cafb6cc4c32897
Reviewed-on: https://chromium-review.googlesource.com/695108Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48261}

The context is the following proposal to make JSON a subset of
JavaScript: https://github.com/tc39/proposal-json-superset

There’s interest in performing a side investigation to answer the
question of what would happen if we stopped treating U+2028 and U+2029
as `LineTerminator`s *entirely*. (Note that this is separate from the
proposal, which just changes how these characters are handled in
ECMAScript strings.) This is technically a breaking change, and IMHO it
would be wonderful if we could get away with it, but no one really has
any data on whether or not we could. Adding this use counter lets us get
that data.

BUG=v8:6827

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia22e8db1634df4d3f965bec8e1cfa11cc7b5e9aa
Reviewed-on: https://chromium-review.googlesource.com/693155
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48260}

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

Change-Id: I3b7e5f4fb9bc6cdad3582e19099fb97b2a0c7cb0
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/684185Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48258}

The KEYED_STORE_IC was never able to deal with stores to typed arrays
where the value being stored is not already a Number (i.e. either a Smi
or a HeapNumber). By extending it to also handle Oddballs (i.e. true,
false, undefined and null) and teaching TurboFan to also perform the
appropriate check plus the truncation to Number, we can easily support
this use case as well.

On the micro-benchmark in the bug report, we go from

  typedArrayStoreBool: 2975 ms.
  typedArrayStoreInt: 44 ms.

to

  typedArrayStoreBool: 43 ms.
  typedArrayStoreInt: 44 ms.

so that's roughly a 70x performance boost.

Bug: chromium:287773
Change-Id: I227419aeabc3f5b6793aa280a95448d03ac2f2dd
Reviewed-on: https://chromium-review.googlesource.com/691731
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48257}

R=gdeepti@chromium.org

Bug: 
Change-Id: Ic2e519d24354b3327a92daa0d4d6e06c9ca4605e
Reviewed-on: https://chromium-review.googlesource.com/687056
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48256}

With --wasm-trace-memory, both compiled code and the interpreter will
output each memory load or store. This helps to debug miscompilations in
emscripten or in V8, like the referenced bug.

R=titzer@chromium.org

Bug: chromium:718858
Change-Id: I90704d164975b11c65677f86947ab102242d5153
Reviewed-on: https://chromium-review.googlesource.com/684316Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48255}

The TypedArray.prototype[Symbol.toStringTag] getter is currently the best (and
as far as I can tell only definitely side-effect free) way to check whether an
arbitrary object is a TypedArray - either generally TypedArray or a specific
one like Uint8Array. Using the getter is thus emerging as the general pattern
to detect TypedArrays, even Node.js now adapted it starting with

  https://github.com/nodejs/node/pull/15663

for the isTypedArray and isUint8Array type checks in lib/internal/util/types.js
now.

The getter returns either the string with the TypedArray subclass name
(i.e. "Uint8Array") or undefined if the receiver is not a TypedArray.
This can be implemented with a simple elements kind dispatch, instead of
checking the instance type and then loading the class name from the
constructor, which requires a loop walking up the transition tree. This
CL ports the builtin to CSA and TurboFan, and changes the logic to a
simple elements kind check. On the micro-benchmark mentioned in the
referenced bug, the time goes from

  testIsArrayBufferView: 565 ms.
  testIsTypedArray: 2403 ms.
  testIsUint8Array: 3847 ms.

to

  testIsArrayBufferView: 566 ms.
  testIsTypedArray: 965 ms.
  testIsUint8Array: 965 ms.

which presents an up to 4x improvement.

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

Change-Id: Iac4a95a0c094472d887d89bbf5d6189988c56f7c
Reviewed-on: https://chromium-review.googlesource.com/692016
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48253}

Bug: V8:6532
Change-Id: I6713e1c01ec669b7fa9a09bb75fbecff12f6cc22
Reviewed-on: https://chromium-review.googlesource.com/685949
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48252}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/b376554..ce6d3d8

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

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

- Moves leak sanitizer code to callers of OS:: Memory functions.
- Changes signature of OS::ReleasePartialRegion to be more generic,
  removing the parameters that only make sense as part of VirtualMemory.

Bug: chromium:756050
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I2f1401c9b0856b2eaf36b80b5f141e935ef63e1c
Reviewed-on: https://chromium-review.googlesource.com/685741Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48250}

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/b6bab93..8ec7b14

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

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

Remove more "using" statements.

Bug: chromium:746958
Change-Id: I2f9c45b1ff1d51fc58b7a702fee046ba3c6a7c17
Reviewed-on: https://chromium-review.googlesource.com/693862Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@vewd.com>
Cr-Commit-Position: refs/heads/master@{#48248}

This improves performance of ArrayBuffer.isView by roughly 2.5x itself,
and enables optimizations across ArrayBuffer.isView calls, i.e. map
checks can be eliminated across. This was discovered in a related Node
pull request (https://github.com/nodejs/node/pull/15663).

Bug: v8:6868
Change-Id: I1d56ec385f8daa0e1d44d3bc4d6c9a5558ba4522
Reviewed-on: https://chromium-review.googlesource.com/691660Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48247}