1. 28 Jun, 2019 1 commit
  2. 27 May, 2019 3 commits
    • Benedikt Meurer's avatar
      Reland "[typedarray] Move external/data pointer to JSTypedArray." · 70bd7cf0
      Benedikt Meurer authored
      This is a reland of 4b86fea5 with
      copy&paste typo in CodeStubAssembler::AllocateByteArray() fixed
      (bug led to holes in new space, which was crashing reproducibly
      on the ia32 bot).
      
      Original change's description:
      > [typedarray] Move external/data pointer to JSTypedArray.
      >
      > As the next step in supporting huge typed arrays in V8, this moves the
      > external/data pointer from the FixedTypedArrayBase backing store to the
      > JSTypedArray instance itself, and replaces the special backing stores
      > with a plain ByteArray (removing all the code for the FixedTypedArrayBase
      > class hierarchy). By doing so, we can drastically simplify the system
      > around typed arrays.
      >
      > Note: Several places in the code base used to check the instance type
      > of the elements backing store of a JSTypedArray instead of checking the
      > elements kind on the JSTypedArray map directly. Those had to be fixed,
      > since the backing store is now always a ByteArray.
      >
      > Drive-by-fix: Move all the typed elements access related code into the
      > elements.cc file to properly encapsulate the accesses.
      >
      > Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
      > Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
      > Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
      > Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61855}
      
      Tbr: petermarshall@chromium.org
      Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
      Change-Id: I87fcdb28532c5f08cc227332a4d59546cb423810
      Cq-Include-Trybots: luci.chromium.try:linux-rel, win7-rel
      Cq-Include-Trybots: luci.v8.try:v8_linux_shared_compile_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631592Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61864}
      70bd7cf0
    • Clemens Hammacher's avatar
      Revert "[typedarray] Move external/data pointer to JSTypedArray." · e4db146a
      Clemens Hammacher authored
      This reverts commit 4b86fea5.
      
      Reason for revert: Fails on linux shared: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20shared/31045
      
      Original change's description:
      > [typedarray] Move external/data pointer to JSTypedArray.
      > 
      > As the next step in supporting huge typed arrays in V8, this moves the
      > external/data pointer from the FixedTypedArrayBase backing store to the
      > JSTypedArray instance itself, and replaces the special backing stores
      > with a plain ByteArray (removing all the code for the FixedTypedArrayBase
      > class hierarchy). By doing so, we can drastically simplify the system
      > around typed arrays.
      > 
      > Note: Several places in the code base used to check the instance type
      > of the elements backing store of a JSTypedArray instead of checking the
      > elements kind on the JSTypedArray map directly. Those had to be fixed,
      > since the backing store is now always a ByteArray.
      > 
      > Drive-by-fix: Move all the typed elements access related code into the
      > elements.cc file to properly encapsulate the accesses.
      > 
      > Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
      > Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
      > Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
      > Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61855}
      
      TBR=ulan@chromium.org,yangguo@chromium.org,titzer@chromium.org,sigurds@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org,szuend@chromium.org
      
      Change-Id: I0bc1f935de6063acf75a0f4bb8c0ba67428603fd
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
      Cq-Include-Trybots: luci.chromium.try:linux-rel, win7-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631427Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61856}
      e4db146a
    • Benedikt Meurer's avatar
      [typedarray] Move external/data pointer to JSTypedArray. · 4b86fea5
      Benedikt Meurer authored
      As the next step in supporting huge typed arrays in V8, this moves the
      external/data pointer from the FixedTypedArrayBase backing store to the
      JSTypedArray instance itself, and replaces the special backing stores
      with a plain ByteArray (removing all the code for the FixedTypedArrayBase
      class hierarchy). By doing so, we can drastically simplify the system
      around typed arrays.
      
      Note: Several places in the code base used to check the instance type
      of the elements backing store of a JSTypedArray instead of checking the
      elements kind on the JSTypedArray map directly. Those had to be fixed,
      since the backing store is now always a ByteArray.
      
      Drive-by-fix: Move all the typed elements access related code into the
      elements.cc file to properly encapsulate the accesses.
      
      Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
      Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
      Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
      Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61855}
      4b86fea5
  3. 23 May, 2019 2 commits
  4. 13 Feb, 2019 1 commit
  5. 09 Jan, 2019 1 commit
  6. 26 Dec, 2018 1 commit
  7. 08 Dec, 2018 1 commit
  8. 05 Nov, 2018 1 commit
  9. 17 Aug, 2018 1 commit
  10. 30 Jul, 2018 1 commit
  11. 26 Jul, 2018 1 commit
  12. 24 Jul, 2018 2 commits
  13. 05 Jul, 2018 1 commit
  14. 03 Jul, 2018 1 commit
    • Dan Elphick's avatar
      [explicit isolates] Add ReadOnlyRoots · ff32ba8e
      Dan Elphick authored
      Adds a ReadOnlyRoots class trivially constructable from a Heap* or
      Isolate* and which can be obtained from a any HeapObject which provides
      access to roots objects that will always be in RO_SPACE. In the longer
      term this object will be accessed via a global variable without
      requiring an Isolate or using the memory address of a HeapObject to
      infer it.
      
      Moves the list macros in heap.h to roots.h and splits some of them into
      two parts (read-only and mutable).
      
      Convert cases of heap_object->GetHeap()->root_accessor() to
      heap_objects->GetReadOnlyRoots().root_accessor().
      
      Bug: v8:7786
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: I14b01052adb2af9a5ec82b970e933d6a423d17a5
      Reviewed-on: https://chromium-review.googlesource.com/1122127
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54160}
      ff32ba8e
  15. 24 May, 2018 1 commit
  16. 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
  17. 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
  18. 20 Mar, 2018 1 commit
  19. 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
  20. 07 Feb, 2018 1 commit
  21. 16 Jan, 2018 1 commit
  22. 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
  23. 09 Jan, 2018 1 commit
  24. 23 Oct, 2017 1 commit
  25. 17 Oct, 2017 1 commit