Skip to content

V
V8
Switch branch/tag
  1. 10 May, 2019 4 commits
  3. 09 May, 2019 2 commits
  5. 07 May, 2019 5 commits
  7. 06 May, 2019 2 commits
  9. 03 May, 2019 1 commit
  11. 02 May, 2019 1 commit
    • Peter Marshall's avatar
      Revert "[typedarray] Make JSTypedArray::length authoritative." · 18100666
      Peter Marshall authored 
      This reverts commit ad44c258.

Reason for revert: Missed some users: crbug.com/v8/9105

Original change's description:
> [typedarray] Make JSTypedArray::length authoritative.
>
> This is the first step towards full huge typed array support in V8.
> Before this change, the JSTypedArray::length and the elements backing
> store length (FixedTypedArrayBase::length) were used more or less
> interchangeably to determine the number of elements in a JSTypedArray.
>
> With this change we disentangle these two lengths, and instead make
> JSTypedArray::length authoritative. For on-heap typed arrays, the
> FixedTypedArrayBase::length will remain the number of elements in the
> backing store, but for the off-heap typed arrays, this length will be
> set to 0 (matching the fact that the FixedTypedArrayBase instance does
> not contain any elements itself).
>
> This also unifies the JSTypedArray::set_/length() and length_value()
> methods to only have JSTypedArray::set_/length() which returns/takes
> size_t values. Currently this still requires the values to be in Smi
> range, but later we will extend this to allow arbitrary size_t values
> (in the safe integer range).
>
> Bug: v8:4153, v8:7881
> Change-Id: Iff9089130bb31fa9e08e0cf913e7ab52c3dbf107
> Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
> Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1543729
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60648}

TBR=jarin@chromium.org,titzer@chromium.org,hpayer@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

TBR=jarin@chromium.org, szuend@chromium.org

Bug: v8:4153, v8:7881
Change-Id: I96992bff15b4a2765ae4a557d2c37e78269c927d
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593294
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61172}
      18100666
  13. 29 Apr, 2019 2 commits
    • Benedikt Meurer's avatar
      [runtime] Optimize general object spread. · 4995c85f
      Benedikt Meurer authored 
      This adds a new %_CopyDataProperties intrinsic, that reuses most of the
existing machinery that we already have in place for Object.assign() and
computed property names in object literals. This speeds up the general
case for object spread (where the spread is not the first item in an
object literal) and brings it on par with Object.assign() at least - in
most cases it's significantly faster than Object.assign().

In the test case [1] referenced from the bug, the performance goes from

  objectSpreadLast: 3624 ms.
  objectAssignLast: 1938 ms.

to

  objectSpreadLast: 646 ms.
  objectAssignLast: 1944 ms.

which corresponds to a **5-6x performance boost**, making object spread
faster than Object.assign() in general.

Drive-by-fix: This refactors the Object.assign() fast-path in a way that
it can be reused appropriately for object spread, and adds another new
builtin SetDataProperties, which does the core of the Object.assign()
work. We can teach TurboFan to inline Object.assign() based on the new
SetDataProperties builtin at some later point to further optimize
Object.assign().

[1]: https://gist.github.com/bmeurer/0dae4a6b0e23f43d5a22d7c91476b6c0

Bug: v8:9167
Change-Id: I57bea7a8781c4a1e8ff3d394873c3cd4c5d73834
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587376Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61100}
      4995c85f
    • Clemens Hammacher's avatar
      [cleanup] Use Vector::begin instead of Vector::start · 4b0f9c85
      Clemens Hammacher authored 
      Our {Vector} template provides both {start} and {begin} methods. They
return exactly the same value. Since the {begin} method is needed for
iteration, and is also what standard containers provide, this CL
switches all uses of the {start} method to use {begin} instead.

Patchset 1 was auto-generated by using this clang AST matcher:
    callExpr(
        callee(
          cxxMethodDecl(
            hasName("start"),
            ofClass(hasName("v8::internal::Vector")))
        ),
        argumentCountIs(0))

Patchset 2 was created by running clang-format. Patchset 3 then
removes the now unused {Vector::start} method.

R=jkummerow@chromium.org
TBR=mstarzinger@chromium.org,yangguo@chromium.org,verwaest@chromium.org

Bug: v8:9183
Change-Id: Id9f01c92870872556e2bb3f6d5667463b0e3e5c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587381Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61081}
      4b0f9c85
  15. 27 Apr, 2019 1 commit
  17. 26 Apr, 2019 1 commit
    • Ross McIlroy's avatar
      Revert "[csa] verify skipped write-barriers in MemoryOptimizer" · dd6c9536
      Ross McIlroy authored 
      This reverts commit da7322c0.

Reason for revert: Breaking the pointer compression bots, e.g.:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20pointer%20compression/3047

Original change's description:
> [csa] verify skipped write-barriers in MemoryOptimizer
> 
> With very few exceptions, this verifies all skipped write-barriers in
> CSA and Torque, showing that the MemoryOptimizer together with some
> type information on the stored value are enough to avoid unsafe skipped
> write-barriers.
> 
> Changes to CSA:
> SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
> MemoryOptimizer by default.
> Type information about the stored values (TNode<Smi>) is exploited to
> safely skip write barriers for stored Smi values.
> In some cases, the code is re-structured to make it easier to consume
> for the MemoryOptimizer (manual branch and load elimination).
> 
> Changes to the MemoryOptimizer:
> Improve the MemoryOptimizer to remove write barriers:
> - When the store happens to a CSA-generated InnerAllocate, by ignoring
>   Bitcasts and additions.
> - When the stored value is the HeapConstant of an immortal immovable root.
> - When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
> - Fast C-calls are treated as non-allocating.
> - Runtime calls can be white-listed as non-allocating.
> 
> Remaining missing cases:
> - C++-style iterator loops with inner pointers.
> - Inner allocates that are reloaded from a field where they were just stored
>   (for example an elements backing store). Load elimination would fix that.
> - Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
>   We could handle that in Torque.
> - Double-aligned allocations, which are not lowered in the MemoryOptimizer
>   but in CSA.
> 
> Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
> can be handled by overload resolution (in Torque and C++).
> 
> R=​jarin@chromium.org
> TBR=mvstanton@chromium.org
> 
> Change-Id: I0af9b710673f350e0fe81c2e59f37da93c024b7c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571414
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61016}

TBR=mvstanton@chromium.org,jarin@chromium.org,tebbi@chromium.org

Change-Id: I36877cd6d08761726ef8dce8a3e3f2ce3eebe6cf
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585732Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61038}
      dd6c9536
  19. 25 Apr, 2019 4 commits
    • Tobias Tebbi's avatar
      [csa] verify skipped write-barriers in MemoryOptimizer · da7322c0
      Tobias Tebbi authored 
      With very few exceptions, this verifies all skipped write-barriers in
CSA and Torque, showing that the MemoryOptimizer together with some
type information on the stored value are enough to avoid unsafe skipped
write-barriers.

Changes to CSA:
SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
MemoryOptimizer by default.
Type information about the stored values (TNode<Smi>) is exploited to
safely skip write barriers for stored Smi values.
In some cases, the code is re-structured to make it easier to consume
for the MemoryOptimizer (manual branch and load elimination).

Changes to the MemoryOptimizer:
Improve the MemoryOptimizer to remove write barriers:
- When the store happens to a CSA-generated InnerAllocate, by ignoring
  Bitcasts and additions.
- When the stored value is the HeapConstant of an immortal immovable root.
- When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
- Fast C-calls are treated as non-allocating.
- Runtime calls can be white-listed as non-allocating.

Remaining missing cases:
- C++-style iterator loops with inner pointers.
- Inner allocates that are reloaded from a field where they were just stored
  (for example an elements backing store). Load elimination would fix that.
- Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
  We could handle that in Torque.
- Double-aligned allocations, which are not lowered in the MemoryOptimizer
  but in CSA.

Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
can be handled by overload resolution (in Torque and C++).

R=jarin@chromium.org
TBR=mvstanton@chromium.org

Change-Id: I0af9b710673f350e0fe81c2e59f37da93c024b7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571414
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61016}
      da7322c0
    • Simon Zünd's avatar
      Reland "[typedarray] Fix crash when sorting SharedArrayBuffers" · ff3a26af
      Simon Zünd authored 
      This is a reland of 3d846115

Reland changes mjsunit.status to skip the regression test on
all bots except ASAN.

Original change's description:
> [typedarray] Fix crash when sorting SharedArrayBuffers
>
> TypedArray#sort has a fast-path when the user does not provide a
> comparison function. This fast-path utilizes std::sort which operates
> directly on the raw data. Per spec, std::sort requires the "less than"
> operation to be anti-symmetric and transitive.
>
> When sorting SharedArrayBuffers (SAB) that are concurrently modified during
> sorting, the "less than" operator stops being consistent as the
> underlying data is constantly modified. This breaks some invariants
> in std::sort resulting in infinite loops or straight out segfaults.
>
> This CL fixes this by copying the data before sorting SABs and
> writing the sorted result back.
>
> Note: The added regression test is tailored for ASAN bots as a
> normal build would need too many iterations to consistently crash.
>
> R=neis@chromium.org, petermarshall@chromium.org
>
> Bug: v8:9161
> Change-Id: Ic089928652f75865bfdb11e7453806faa6ecb988
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1581641
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61004}

Bug: v8:9161
Change-Id: Idffc3fbb5f28f4966c8f1ac6770d5b5d6003a7e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1583726Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61011}
      ff3a26af
    • Michael Achenbach's avatar
      Revert "[typedarray] Fix crash when sorting SharedArrayBuffers" · a5941ac9
      Michael Achenbach authored 
      This reverts commit 3d846115.

Reason for revert: The test hangs flakily on windows:
https://ci.chromium.org/p/v8/builders/ci/V8%20Win32/20612
https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20nosnap%20-%20shared/33147
https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20debug/19945

Original change's description:
> [typedarray] Fix crash when sorting SharedArrayBuffers
> 
> TypedArray#sort has a fast-path when the user does not provide a
> comparison function. This fast-path utilizes std::sort which operates
> directly on the raw data. Per spec, std::sort requires the "less than"
> operation to be anti-symmetric and transitive.
> 
> When sorting SharedArrayBuffers (SAB) that are concurrently modified during
> sorting, the "less than" operator stops being consistent as the
> underlying data is constantly modified. This breaks some invariants
> in std::sort resulting in infinite loops or straight out segfaults.
> 
> This CL fixes this by copying the data before sorting SABs and
> writing the sorted result back.
> 
> Note: The added regression test is tailored for ASAN bots as a
> normal build would need too many iterations to consistently crash.
> 
> R=​neis@chromium.org, petermarshall@chromium.org
> 
> Bug: v8:9161
> Change-Id: Ic089928652f75865bfdb11e7453806faa6ecb988
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1581641
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61004}

TBR=neis@chromium.org,petermarshall@chromium.org,szuend@chromium.org

Change-Id: I046da3e4228bb1a8a3aa89d9c9d8de11875a9273
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9161
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1583725Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61007}
      a5941ac9
    • Simon Zünd's avatar
      [typedarray] Fix crash when sorting SharedArrayBuffers · 3d846115
      Simon Zünd authored 
      TypedArray#sort has a fast-path when the user does not provide a
comparison function. This fast-path utilizes std::sort which operates
directly on the raw data. Per spec, std::sort requires the "less than"
operation to be anti-symmetric and transitive.

When sorting SharedArrayBuffers (SAB) that are concurrently modified during
sorting, the "less than" operator stops being consistent as the
underlying data is constantly modified. This breaks some invariants
in std::sort resulting in infinite loops or straight out segfaults.

This CL fixes this by copying the data before sorting SABs and
writing the sorted result back.

Note: The added regression test is tailored for ASAN bots as a
normal build would need too many iterations to consistently crash.

R=neis@chromium.org, petermarshall@chromium.org

Bug: v8:9161
Change-Id: Ic089928652f75865bfdb11e7453806faa6ecb988
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1581641Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61004}
      3d846115
  21. 24 Apr, 2019 1 commit
    • Jakob Gruber's avatar
      [coverage] Reduce IncBlockCounter overhead · ae6a47ba
      Jakob Gruber authored 
      When collecting JS block coverage, we track block execution counts on
so-called CoverageInfo objects. Generated bytecode and native code
contains inlined snippets of code to increment the appropriate
counters.

These used to be implemented as calls to the IncBlockCounter runtime
function. Each call incurred the entire CEntry overhead.

This CL reduces that overhead by moving logic over into a new
IncBlockCounter TFS builtin. The builtin is called directly from
bytecode, and lowered to the same builtin call for optimized code.

Drive-by: Tweak CoverageInfo layout to generate faster code.

Tbr: jarin@chromium.org
Bug: v8:9149, v8:6000
Change-Id: I2d7cb0db649edf7c56b5ef5a4683d27b1c34605c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571420Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60981}
      ae6a47ba
  23. 23 Apr, 2019 1 commit
  25. 18 Apr, 2019 1 commit
  27. 17 Apr, 2019 1 commit
    • Clemens Hammacher's avatar
      [wasm] Remove trap handler fallback · c2835df6
      Clemens Hammacher authored 
      The trap handler fallback is flaky, and was never enabled since it
never worked reliably. This CL removes
a) the --wasm-trap-handler-fallback flag,
b) the distinction between soft and hard address space limit,
c) methods to check whether memory has guard regions (it will always
  have them on 64 bit architectures),
d) associated runtime functions,
e) the trap handler fallback tests,
f) recompilation logic for the fallback.

R=titzer@chromium.org

Bug: v8:8746
Change-Id: I7f4682b8cd5470906dd8579ff1fdc9b1a3c0f0e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1570023Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60904}
      c2835df6
  29. 15 Apr, 2019 1 commit
  31. 11 Apr, 2019 2 commits
  33. 09 Apr, 2019 3 commits
  35. 08 Apr, 2019 1 commit
    • Michael Starzinger's avatar
      [wasm] Support reference types on interpreter entry. · 0bed5887
      Michael Starzinger authored 
      This adds preliminary support for references types as argument or return
values to functions that are redirected to the interpreter. The current
interpreter entry stub remains unchanged, using one buffer area that is
hidden from the GC. The corresponding {Runtime_WasmRunInterpreter} now
correctly boxes/un-boxes reference types into handles. This switch to a
handlified representation happens before any method that potentially
triggers a GC is called.

R=clemensh@chromium.org
TEST=mjsunit/wasm/exceptions-anyref-interpreter
BUG=v8:8091,v8:7581

Change-Id: I41c766ed5ac877042d5964e72f3fd7df390c4e98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1557147
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60684}
      0bed5887
  37. 05 Apr, 2019 1 commit
    • Benedikt Meurer's avatar
      [typedarray] Make JSTypedArray::length authoritative. · ad44c258
      Benedikt Meurer authored 
      This is the first step towards full huge typed array support in V8.
Before this change, the JSTypedArray::length and the elements backing
store length (FixedTypedArrayBase::length) were used more or less
interchangeably to determine the number of elements in a JSTypedArray.

With this change we disentangle these two lengths, and instead make
JSTypedArray::length authoritative. For on-heap typed arrays, the
FixedTypedArrayBase::length will remain the number of elements in the
backing store, but for the off-heap typed arrays, this length will be
set to 0 (matching the fact that the FixedTypedArrayBase instance does
not contain any elements itself).

This also unifies the JSTypedArray::set_/length() and length_value()
methods to only have JSTypedArray::set_/length() which returns/takes
size_t values. Currently this still requires the values to be in Smi
range, but later we will extend this to allow arbitrary size_t values
(in the safe integer range).

Bug: v8:4153, v8:7881
Change-Id: Iff9089130bb31fa9e08e0cf913e7ab52c3dbf107
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1543729
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60648}
      ad44c258
  39. 04 Apr, 2019 2 commits
  41. 03 Apr, 2019 2 commits
  43. 02 Apr, 2019 1 commit