1. 29 Jun, 2021 1 commit
  2. 28 Jun, 2021 2 commits
  3. 23 Jun, 2021 1 commit
  4. 19 May, 2021 1 commit
  5. 07 May, 2021 1 commit
  6. 06 May, 2021 2 commits
  7. 14 Oct, 2020 1 commit
  8. 20 Mar, 2020 1 commit
  9. 26 Feb, 2020 1 commit
  10. 09 Jan, 2020 1 commit
  11. 26 Nov, 2019 1 commit
  12. 20 Nov, 2019 1 commit
  13. 15 Nov, 2019 1 commit
  14. 11 Sep, 2019 1 commit
  15. 06 Aug, 2019 1 commit
  16. 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
  17. 24 May, 2019 3 commits
    • Simon Zünd's avatar
      Reland "[array] Move Array#sort pre-processing to Torque" · 843b6646
      Simon Zünd authored
      This is a reland of 2b0ac2fb
      
      The layout test that caused this revert was fixed with:
      https://crrev.com/c/1627386
      
      Original change's description:
      > [array] Move Array#sort pre-processing to Torque
      >
      > This CL removes the "PrepareElementsForSort" runtime function, and
      > replaces it with a simpler version in Torque. The biggest difference
      > is that certain sparse configurations no longer have a fast-path.
      >
      > The Torque pre-processing step replaces the existing Torque mechanism that
      > copied already pre-processed elements into the "work" FixedArray. The Torque
      > compacting works as follows:
      >   - Iterate all elements from 0 to {length}
      >     - If the element is the hole: Do nothing.
      >     - If the element is "undefined": Increment undefined counter.
      >     - In all other cases, push the element into the "work" FixedArray.
      >
      > Then the "work" FixedArray is sorted as before. Writing the elements from
      > the "work" array back into the receiver, after sorting, has three steps:
      >   1. Copy the sorted elements from the "work" FixedArray to the receiver.
      >   2. Add previously counted number of "undefined" to the receiver.
      >   3. Depending on the backing store either delete properties or
      >      set them to the Hole up to {length}.
      >
      > Bug: v8:8714
      > Change-Id: I14eccb7cfd2e4618bce2a85cba0689d7e0380ad2
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619756
      > Commit-Queue: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61812}
      
      TBR: jgruber@chromium.org
      Bug: v8:8714
      Change-Id: If7613f6e5f37c5e0d649e8192195594bc6c32100
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627977
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Auto-Submit: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61827}
      843b6646
    • Simon Zünd's avatar
      Revert "[array] Move Array#sort pre-processing to Torque" · 70eeb22d
      Simon Zünd authored
      This reverts commit 2b0ac2fb.
      
      Reason for revert: Breaks scrollingcoordinator/non-fast-scrollable-region-nested.html layout test on https://ci.chromium.org/p/v8/builders/ci/V8-Blink%20Linux%2064/32241 
      
      Original change's description:
      > [array] Move Array#sort pre-processing to Torque
      > 
      > This CL removes the "PrepareElementsForSort" runtime function, and
      > replaces it with a simpler version in Torque. The biggest difference
      > is that certain sparse configurations no longer have a fast-path.
      > 
      > The Torque pre-processing step replaces the existing Torque mechanism that
      > copied already pre-processed elements into the "work" FixedArray. The Torque
      > compacting works as follows:
      >   - Iterate all elements from 0 to {length}
      >     - If the element is the hole: Do nothing.
      >     - If the element is "undefined": Increment undefined counter.
      >     - In all other cases, push the element into the "work" FixedArray.
      > 
      > Then the "work" FixedArray is sorted as before. Writing the elements from
      > the "work" array back into the receiver, after sorting, has three steps:
      >   1. Copy the sorted elements from the "work" FixedArray to the receiver.
      >   2. Add previously counted number of "undefined" to the receiver.
      >   3. Depending on the backing store either delete properties or
      >      set them to the Hole up to {length}.
      > 
      > Bug: v8:8714
      > Change-Id: I14eccb7cfd2e4618bce2a85cba0689d7e0380ad2
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619756
      > Commit-Queue: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61812}
      
      TBR=peter.wm.wong@gmail.com,jgruber@chromium.org,tebbi@chromium.org,szuend@chromium.org
      
      Change-Id: If1c1bc07f38dfbd4bf6b6ce8f9d70714e7526877
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8714
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627976Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61814}
      70eeb22d
    • Simon Zünd's avatar
      [array] Move Array#sort pre-processing to Torque · 2b0ac2fb
      Simon Zünd authored
      This CL removes the "PrepareElementsForSort" runtime function, and
      replaces it with a simpler version in Torque. The biggest difference
      is that certain sparse configurations no longer have a fast-path.
      
      The Torque pre-processing step replaces the existing Torque mechanism that
      copied already pre-processed elements into the "work" FixedArray. The Torque
      compacting works as follows:
        - Iterate all elements from 0 to {length}
          - If the element is the hole: Do nothing.
          - If the element is "undefined": Increment undefined counter.
          - In all other cases, push the element into the "work" FixedArray.
      
      Then the "work" FixedArray is sorted as before. Writing the elements from
      the "work" array back into the receiver, after sorting, has three steps:
        1. Copy the sorted elements from the "work" FixedArray to the receiver.
        2. Add previously counted number of "undefined" to the receiver.
        3. Depending on the backing store either delete properties or
           set them to the Hole up to {length}.
      
      Bug: v8:8714
      Change-Id: I14eccb7cfd2e4618bce2a85cba0689d7e0380ad2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619756
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61812}
      2b0ac2fb
  18. 23 May, 2019 2 commits
  19. 22 May, 2019 1 commit
  20. 20 May, 2019 4 commits
  21. 17 May, 2019 4 commits
  22. 15 May, 2019 1 commit
  23. 07 May, 2019 1 commit
    • Peter Marshall's avatar
      Reland "[typedarray] Make JSTypedArray::length authoritative." · 330e5ba2
      Peter Marshall authored
      This is a reland of ad44c258
      
      Patchset 2 is the original CL
      Patchset 3 fixes some misuses of FixedArrayBase::length() and adds some
      DCHECKS to flush out any more misuses.
      Patchset 4 adds the PPC/S390 port by miladfar@ca.ibm.com.
      
      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}
      
      Bug: v8:4153, v8:7881, v8:9105
      Change-Id: Ic38f833071a723642ebc6f82a4012dbc0878ef98
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594435Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61275}
      330e5ba2
  24. 12 Mar, 2019 1 commit
  25. 08 Mar, 2019 1 commit
    • Jakob Kummerow's avatar
      [ubsan] Fix two more UBSan issues · 34b467e1
      Jakob Kummerow authored
      RotateRight32 needs a "number of bits" operand in the range 0..31.
      Thankfully that's how x86 shift instructions behave anyway, and
      how the bitwise shift operators in JavaScript are spec'ed, so this
      fix is unobservable in non-UBSan builds.
      
      RemoveArrayHolesGeneric can be used for length values anywhere in
      the uint32_t range, so it must not implicitly cast those to int.
      That actually caused an observable bug where a proxy's traps would
      not get called at all, but only for huge "length" properties, where
      the entire operation would also be painfully slow.
      
      Bug: chromium:935133, chromium:937652
      Change-Id: I13f74ca27eae6b2b089d58217842b699b2574509
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1510272
      Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60112}
      34b467e1
  26. 15 Feb, 2019 1 commit
  27. 29 Jan, 2019 1 commit