1. 20 Mar, 2020 1 commit
  2. 26 Feb, 2020 1 commit
  3. 09 Jan, 2020 1 commit
  4. 26 Nov, 2019 1 commit
  5. 20 Nov, 2019 1 commit
  6. 15 Nov, 2019 1 commit
  7. 11 Sep, 2019 1 commit
  8. 06 Aug, 2019 1 commit
  9. 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
  10. 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
  11. 23 May, 2019 2 commits
  12. 22 May, 2019 1 commit
  13. 20 May, 2019 4 commits
  14. 17 May, 2019 4 commits
  15. 15 May, 2019 1 commit
  16. 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
  17. 12 Mar, 2019 1 commit
  18. 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
  19. 15 Feb, 2019 1 commit
  20. 29 Jan, 2019 1 commit
  21. 25 Jan, 2019 1 commit
    • Mythri's avatar
      Defer inferring language mode as far as possible · 592aeefa
      Mythri authored
      Inferring the language mode involves iterating the stack to find the
      closure. This is an expensive operation and should be done only when
      required. This cl changes the implementation to infer the language
      mode only when we can't defer it any further. Currently, we infer the
      language mode when throwing an exception or when passing this
      information to PropertyCallbackArguments.
      
      This cl also changes the language mode parameter to SetProperty
      related methods to Maybe<ShouldThrow>. We only use the language mode to
      decide if we need to throw and using ShouldThrow instead of language
      mode simplifies the code by avoiding conversions from Maybe<ShouldThrow>
      to Maybe<LanguageMode> and vice-versa.
      
      Bug: v8:8580, chromium:923820, chromium:925289
      Change-Id: I72497497f62fe0d86fcecd57b06b3183b7531f7b
      Reviewed-on: https://chromium-review.googlesource.com/c/1425912
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59094}
      592aeefa
  22. 22 Jan, 2019 1 commit
  23. 18 Jan, 2019 1 commit
    • Simon Zünd's avatar
      [array] Remove CHECK_LE from RemoveArrayHolesGeneric · e38faab1
      Simon Zünd authored
      This CL removes a CHECK_LE that does not hold in all cases. After
      moving all elements to the front, current_pos will point to the next
      free spot. In the case where an object is 'packed', i.e. each index
      has a non-undefined value, and the length is smaller then the max
      index, current_pos will be greater than the length (limit in the code).
      
      Sidenote: The block after taking the minimum (where the counted
      undefineds get set) will not be affected. In the case where
      num_undefined > 0, current_pos should be guaranteed to be smaller
      than limit, as long there are no accessors with side-effects.
      
      R=jgruber@chromium.org
      
      Bug: chromium:923265
      Change-Id: Id533cdc4db6c6c6f266cf7c6a8ab6ecbbeee7016
      Reviewed-on: https://chromium-review.googlesource.com/c/1420679Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58912}
      e38faab1
  24. 17 Jan, 2019 1 commit
    • Simon Zünd's avatar
      [array] Fix prototype chain interaction in sort pre-processing · 4bf28a33
      Simon Zünd authored
      This CL fixes two bugs. First, when looking for a free spot while
      moving elements to the front, the prototype chain was also considered,
      even though an object at a specific index might have a hole (free
      spot).
      
      Second, when moving an element to the front, we are not allowed to
      delete it immediately (to preserve semantics when interacting with
      non-extensible objects). Such an element is then a free spot, but
      won't be recognised as such. This CL sets that element to undefined
      after it was moved, to mark it as a free spot.
      
      R=jgruber@chromium.org
      
      Bug: chromium:897512,v8:8369
      Change-Id: I79207215b8b0a3c714f064450d8fe5ca0ea4a096
      Reviewed-on: https://chromium-review.googlesource.com/c/1417171
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58878}
      4bf28a33
  25. 26 Dec, 2018 1 commit
  26. 08 Dec, 2018 1 commit
  27. 07 Dec, 2018 3 commits