Skip to content

V
V8
Switch branch/tag
  1. 26 Dec, 2018 1 commit
  3. 11 Dec, 2018 1 commit
  5. 08 Dec, 2018 1 commit
  7. 22 Nov, 2018 1 commit
  9. 21 Nov, 2018 1 commit
  11. 21 Sep, 2018 1 commit
  13. 20 Sep, 2018 1 commit
    • Michael Achenbach's avatar
      Revert "[es2015] Introduce JSDataView::external_pointer." · ec216398
      Michael Achenbach authored 
      This reverts commit 46573e51.

Reason for revert: Speculative revert for breaking chromium integration.

Might break gpu tests and linux debug:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/Mac%20V8%20FYI%20Release%20(Intel)/2554

Also blocks the roll:
https://chromium-review.googlesource.com/c/chromium/src/+/1234328

Original change's description:
> [es2015] Introduce JSDataView::external_pointer.
> 
> This adds a new external_pointer field to every JSDataView instance
> which points directly into the backing store at the given view's
> byte_offset. This was the DataView performance is now almost on
> par with the TypedArray performance for accessing aligned memory
> (with appropriate endianess). This also serves as prepatory work
> to enable full 64-bit addressing of DataView backing stores in
> optimized code (soonish).
> 
> This change optimizes the bounds checking sequence in TurboFan in
> such a way that it further improves the DataView set/get performance
> by around 10%, almost closing the remaining gap between DataViews
> and TypedArrays.
> 
> Drive-by-fix: Get rid of the code duplication around DataView inlining
> in the JSCallReducer and have only a single bottleneck method now.
> 
> Bug: chromium:225811, v8:4153, v8:7881, v8:8171
> Change-Id: I9118efd4d19e93f0e51c931a9bec1a56a0f4593e
> Reviewed-on: https://chromium-review.googlesource.com/1231994
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56042}

TBR=yangguo@chromium.org,mlippautz@chromium.org,tebbi@chromium.org,bmeurer@chromium.org

Change-Id: I614a90043b1574b19936c37987db94806cac3bd7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:225811, v8:4153, v8:7881, v8:8171
Reviewed-on: https://chromium-review.googlesource.com/1234417Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56059}
      ec216398
  15. 19 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [es2015] Introduce JSDataView::external_pointer. · 46573e51
      Benedikt Meurer authored 
      This adds a new external_pointer field to every JSDataView instance
which points directly into the backing store at the given view's
byte_offset. This was the DataView performance is now almost on
par with the TypedArray performance for accessing aligned memory
(with appropriate endianess). This also serves as prepatory work
to enable full 64-bit addressing of DataView backing stores in
optimized code (soonish).

This change optimizes the bounds checking sequence in TurboFan in
such a way that it further improves the DataView set/get performance
by around 10%, almost closing the remaining gap between DataViews
and TypedArrays.

Drive-by-fix: Get rid of the code duplication around DataView inlining
in the JSCallReducer and have only a single bottleneck method now.

Bug: chromium:225811, v8:4153, v8:7881, v8:8171
Change-Id: I9118efd4d19e93f0e51c931a9bec1a56a0f4593e
Reviewed-on: https://chromium-review.googlesource.com/1231994
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56042}
      46573e51
  17. 18 Sep, 2018 1 commit
  19. 17 Sep, 2018 2 commits
    • Benedikt Meurer's avatar
      [cleanup] Cleanup JSArrayBuffer and TurboFan's handling of neutering. · beebb236
      Benedikt Meurer authored 
      Cleanup the JSArrayBuffer bit fields to use the proper object macros
that are now otherwise used consistently across the code base. Also
change TurboFan to consistently bailout when it sees an array buffer
that was previously neutered, so that the generic path / builtins are
again the chokepoints for the spec violations (the fact that we don't
always raise exceptions when we see a neutered array buffer), except
for the ArrayBufferView accessor inlining in the JSCallReducer, where
we still turn the values into zero (because we don't have access to
a CALL_IC speculation guard in the common case).

This also removes the ArrayBufferWasNeutered simplified operator, and
does regular LoadField + Number bitwise operations instead, which is
good enough and allows us to get rid of a lot of unnecessary complexity.

Bug: v8:4153, v8:7881, v8:8015, v8:8171, v8:8178
Change-Id: I4ce79ece762c632e6318f2ab7bcc6b2f82383947
Reviewed-on: https://chromium-review.googlesource.com/1226887Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55958}
      beebb236
    • Marja Hölttä's avatar
      [in-place weak refs] Cleanup: remove BodyDescriptorWeak typedefs · 4eefb396
      Marja Hölttä authored 
      BodyDescriptorWeak is not needed for all classes. For the classes it's needed
it's referred to explicitly (Foo::BodyDescriptorWeak::IterateBody()).

BUG=v8:7308

Change-Id: If8591929cd588575e88f3d6f116ec2cac4941e8f
Reviewed-on: https://chromium-review.googlesource.com/1226649Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55941}
      4eefb396
  21. 13 Sep, 2018 1 commit
  23. 10 Sep, 2018 1 commit
  25. 17 Aug, 2018 1 commit
  27. 24 Jul, 2018 1 commit
    • Ben L. Titzer's avatar
      [wasm] Prepare to support 4GiB memories · dab10765
      Ben L. Titzer authored 
      This is a preparatory CL that refactors the WASM memory allocation path,
the WasmGraphBuilder, and several points of contact for ArrayBuffers to
allow them to eventually be up to 4GiB.

1.) Refactor definition of constants to prepare for memories of size 2^32
2.) Refactor WasmInstanceObject fields memory_size and memory_mask to
    be stored as uintptr_t
3.) Refactor WasmGraphBuilder to use 64-bit comparisons for bounds checks
4.) Refactor JSArrayBuffer accessor methods to use size_t properly.
5.) Add empirical maximum memory and array buffer size tests

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

Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I78a49069cfa89757cc93f0a30b1c1a99c4b2edba
Reviewed-on: https://chromium-review.googlesource.com/1112003
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54646}
      dab10765
  29. 16 Jul, 2018 1 commit
  31. 12 Jul, 2018 1 commit
    • Leszek Swirski's avatar
      [cleanup] Remove Isolate parameter from object print · 13b899a5
      Leszek Swirski authored 
      With ReadOnlyRoots and GetIsolate on JSReceiver, we can remove almost
every isolate parameter from <Object>::Print. The remaining ones, like
Map, are special-caseable for read-only maps, and as a result we can
remove isolate parameters from <Object>::Print entirely.

This patch also opportunistically cleans up a few places where isolates
were only needed for Object::Print, such as TransitionAccessors and
DescriptorArrays.

TBR=yangguo@chromium.org,mstarzinger@chromium.org

Bug: v8:7786
Change-Id: Id44bd53b9893e679eea5f37b9548257595a1bfd9
Reviewed-on: https://chromium-review.googlesource.com/1133385Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54401}
      13b899a5
  33. 06 Jul, 2018 1 commit
  35. 05 Jul, 2018 1 commit
  37. 28 Jun, 2018 1 commit
    • Ben Smith's avatar
      [wasm] postMessage of WebAssembly.Module in d8 · c9b4f805
      Ben Smith authored 
      Supporting postMessage from WebAssembly.Module requires implementing
some logic in the ValueSerializer and ValueDeserializer delegates. This
change implements some simple logic for d8.

This change also fixes a DCHECK that occurs when sending a shared
WebAssembly.Memory object to two Workers.

Bug: chromium:857049
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Idddb23a48175c7175967af3fbc03d8572452a069
Reviewed-on: https://chromium-review.googlesource.com/1117871Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54093}
      c9b4f805
  39. 26 Jun, 2018 1 commit
  41. 02 May, 2018 1 commit
    • Michael Lippautz's avatar
      [heap] Fix ArrayBufferTracker accessing already swept byte length · 55d00c95
      Michael Lippautz authored 
      The tracker needs to maintain the byte length as there is no order guarantee
when sweeping pages and the byte length may be a HeapNumber that is stored on a
different page.

The abstraction for ArrayBuffers is left untouched. We distinguish between the
following cases:
1. Regular AB (backing_store and bye_length should be used)
2. AB allocated using kReservation but not part of wasm
3. AB allocated using kReservation and part of wasm

In practice, 2. does not exist, but we still maintain "allocation_base" and
"allocation_length" which fall back to backing_store and byte_length in this
case. The problematic part is that they look like innocent getters on the
object but actually refer to different data structures or on-heap objects.

Since 2. does not exist, and 3. looks up the bounds in its own tracker, it is
fine for ArrayBufferTracker to pass backing_store and tracked byte_length.

Bug: v8:7701
Change-Id: Ib89d5fe94fce5cef8e5d8343a5415a3b9ad0deba
Reviewed-on: https://chromium-review.googlesource.com/1039385Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52923}
      55d00c95
  43. 10 Apr, 2018 1 commit
  45. 09 Apr, 2018 1 commit
  47. 06 Apr, 2018 1 commit
  49. 05 Apr, 2018 1 commit
    • Peter Marshall's avatar
      [typedarray] Fix GetBuffer for 0-length off-heap typed arrays. · eab5583a
      Peter Marshall authored 
      Fixes a crash that happens when calling postMessage on an empty typed
array.

GetBuffer should only call MaterializeArrayBuffer for on-heap buffers,
but the on-heap check is slightly wrong. This CL moves the on-heap check
logic to the JSTypedArray class so that other parts of the codebase
don't need to worry about how that is determined.

Also add some dchecks to materialize itself. It should only receive
on-heap buffers and should always transform them to off-heap buffers.
There is also no reason for it to be static, so change that here too.

Bug: chromium:797588
Change-Id: Icd88a5b68e424d82c9f1f7889ca42a40a72a1bdc
Reviewed-on: https://chromium-review.googlesource.com/995898
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52388}
      eab5583a
  51. 24 Mar, 2018 1 commit
  53. 22 Mar, 2018 1 commit
    • Eric Holk's avatar
      [wasm] always allocate memory when guard regions are needed · d31dff84
      Eric Holk authored 
      When using trap handlers, memory references do not get any checks inserted. This
means there is no check for a null memory as happens when the memory size is
0. Normally this would be correctly caught as an out of bounds access, since the
low memory addresses are not normally mapped. However, if they were mapped for
some reason, we would not catch the out of bounds access.

The fix is to ensure WebAssembly instances always have a guard region even if
the memory is size 0.

This is a rewrite of 5e76ff5a

Note that this can lead to a large amount of unnecessary address space usage,
so we share a single reservation for empty array buffers.

Bug: chromium:769637

Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Ia8e84be6d595e347d3d342959f2c374db1a3f683
Reviewed-on: https://chromium-review.googlesource.com/702657Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52163}
      d31dff84
  55. 20 Mar, 2018 1 commit
  57. 05 Mar, 2018 1 commit
    • Benedikt Meurer's avatar
      [es2015] Refactor the JSArrayIterator. · 06ee127b
      Benedikt Meurer authored 
      This changes the JSArrayIterator to always have only a single instance
type, instead of the zoo of instance types that we had before, and
which became less useful with the specification update to when "next"
is loaded from the iterator now. This greatly simplifies the baseline
implementation of the array iterator, which now only looks at the
iterated object during %ArrayIteratorPrototype%.next invocations.

In TurboFan we introduce a new JSCreateArrayIterator operator, that
holds the IterationKind and get's the iterated object as input. When
optimizing %ArrayIteratorPrototype%.next in the JSCallReducer, we
check whether the receiver is a JSCreateArrayIterator, and if so,
we try to infer maps for the iterated object from there. If we find
any, we speculatively assume that these won't have changed during
iteration (as we did before with the previous approach), and generate
fast code for both JSArray and JSTypedArray iteration.

Drive-by-fix: Drop the fast_array_iteration protector, it's not
necessary anymore since we have the deoptimization guard bit in
the JSCallReducer now.

This addresses the performance cliff noticed in webpack 4. The minimal
repro on the tracking bug goes from

  console.timeEnd: mono, 124.773000
  console.timeEnd: poly, 670.353000

to

  console.timeEnd: mono, 118.709000
  console.timeEnd: poly, 141.393000

so that's a 4.7x improvement.

Also make presubmit happy by adding the missing #undef's.

Bug: v8:7510, v7:7514
Change-Id: I79a46bfa2cd0f0710e09365ef72519b1bbb667b5
Reviewed-on: https://chromium-review.googlesource.com/946098Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51725}
      06ee127b
  59. 07 Feb, 2018 2 commits
  61. 16 Jan, 2018 1 commit
  63. 10 Jan, 2018 1 commit
    • Jakob Gruber's avatar
      Revert "Optimize TypedArraySpeciesCreate using SpeciesProtector of Array" · b131cc35
      Jakob Gruber authored 
      This reverts commit 8fbc6a05.

Reason for revert: https://crbug.com/800356

Original change's description:
> Optimize TypedArraySpeciesCreate using SpeciesProtector of Array
> 
> If there is no constructor or species updates on Array or TypedArrays,
> then skip lookups of constructor and species so that we can create a new
> typed array quickly. This path makes TA.p.slice() 4x faster in fast
> cases.
> 
> Bug: v8:7161
> Change-Id: Ib8d2a3f6b8b5ed356c5822a814164166d1285f64
> Reviewed-on: https://chromium-review.googlesource.com/828343
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50423}

TBR=jkummerow@chromium.org,jgruber@chromium.org,ishell@chromium.org,bmeurer@chromium.org,cwhan.tunz@gmail.com

Change-Id: Icca07564d2a83710852eb797bac25f1d5600696e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7161
Reviewed-on: https://chromium-review.googlesource.com/859156Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50470}
      b131cc35
  65. 09 Jan, 2018 1 commit
  67. 01 Dec, 2017 1 commit
  69. 28 Nov, 2017 1 commit
  71. 20 Nov, 2017 3 commits
    • Peter Marshall's avatar
      reland: [heap] Concurrently free ArrayBuffer allocations. · d8981833
      Peter Marshall authored 
      Free ArrayBuffer backing stores on a background thread, rather than
blocking the main thread after processing. Could potentially cause
contention with the array buffer allocator once JS execution resumes.

The new ArrayBufferCollector class tracks these dead allocations.

Later, the processing of array buffers can happen in parallel.

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;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: v8:6992
Change-Id: I2b74f008f79521414374f607ed510f66508af160
Reviewed-on: https://chromium-review.googlesource.com/779182
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49505}
      d8981833
    • Peter Marshall's avatar
      Revert "[heap] Concurrently free ArrayBuffer allocations." · 3b31e5be
      Peter Marshall authored 
      This reverts commit b6658ade.

Reason for revert: Breaks TSAN :(

Original change's description:
> [heap] Concurrently free ArrayBuffer allocations.
> 
> Free ArrayBuffer backing stores on a background thread, rather than
> blocking the main thread after processing. Could potentially cause
> contention with the array buffer allocator once JS execution resumes.
> 
> The new ArrayBufferCollector class tracks these dead allocations.
> 
> Later, the processing of array buffers can happen in parallel.
> 
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> 
> Bug: v8:6992
> Change-Id: I49ae4db12ed62d8400ba2bbafeda05a11479d904
> Reviewed-on: https://chromium-review.googlesource.com/739829
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49485}

TBR=hpayer@chromium.org,mlippautz@chromium.org,petermarshall@chromium.org

Change-Id: If6743b83f871c0fd0d6e83a3083dce0eecd99021
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6992
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/779159Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49488}
      3b31e5be
    • Peter Marshall's avatar
      [heap] Concurrently free ArrayBuffer allocations. · b6658ade
      Peter Marshall authored 
      Free ArrayBuffer backing stores on a background thread, rather than
blocking the main thread after processing. Could potentially cause
contention with the array buffer allocator once JS execution resumes.

The new ArrayBufferCollector class tracks these dead allocations.

Later, the processing of array buffers can happen in parallel.

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng

Bug: v8:6992
Change-Id: I49ae4db12ed62d8400ba2bbafeda05a11479d904
Reviewed-on: https://chromium-review.googlesource.com/739829
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49485}
      b6658ade