1. 08 Jul, 2022 1 commit
  2. 10 May, 2022 1 commit
  3. 13 Dec, 2021 1 commit
    • Patrick Thier's avatar
      Reland "[turbofan] Improve StoreStoreElimination" · e926da45
      Patrick Thier authored
      This is a reland of 863bc2b8
      
      Diff to original:
      - Don't eliminate GC observable stores that were temporarily
        unobservable during traversal.
      - Skip the previously added test for single-generation
      - Add new test
      
      Original change's description:
      > [turbofan] Improve StoreStoreElimination
      >
      > Previously, StoreStoreElimination handled allocations as
      > "can observe anything". This is pretty conservative and prohibits
      > elimination of repeated double stores to the same field.
      > With this CL allocations are changed to "observes initializing or
      > transitioning stores".
      > This way it is guaranteed that initializing stores to a freshly created
      > object or stores that are part of a map transition are not eliminated
      > before allocations (that can trigger GC), but allows elimination of
      > non-initializing, non-transitioning, unobservable stores in the
      > presence of allocations.
      >
      > Bug: v8:12200
      > Change-Id: Ie1419696b9c8cb7c39aecf38d9f08102177b2c0f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295449
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78230}
      
      Bug: v8:12200, chromium:1276923, v8:12477
      Change-Id: Ied45ee28ac12b370f7b232d2d338f93e10fea6b4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320460Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Patrick Thier <pthier@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78349}
      e926da45
  4. 07 Dec, 2021 1 commit
    • Patrick Thier's avatar
      Revert "[turbofan] Improve StoreStoreElimination" · 41b9cd7f
      Patrick Thier authored
      This reverts commit 863bc2b8.
      
      Reason for revert: https://crbug.com/1276923
      
      Original change's description:
      > [turbofan] Improve StoreStoreElimination
      >
      > Previously, StoreStoreElimination handled allocations as
      > "can observe anything". This is pretty conservative and prohibits
      > elimination of repeated double stores to the same field.
      > With this CL allocations are changed to "observes initializing or
      > transitioning stores".
      > This way it is guaranteed that initializing stores to a freshly created
      > object or stores that are part of a map transition are not eliminated
      > before allocations (that can trigger GC), but allows elimination of
      > non-initializing, non-transitioning, unobservable stores in the
      > presence of allocations.
      >
      > Bug: v8:12200
      > Change-Id: Ie1419696b9c8cb7c39aecf38d9f08102177b2c0f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295449
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78230}
      
      Bug: chromium:1276923
      Change-Id: I43dc3572ce1ef1fda42b7551ce8210d9f03e36ca
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318666
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Patrick Thier <pthier@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78277}
      41b9cd7f
  5. 03 Dec, 2021 1 commit
    • Patrick Thier's avatar
      [turbofan] Improve StoreStoreElimination · 863bc2b8
      Patrick Thier authored
      Previously, StoreStoreElimination handled allocations as
      "can observe anything". This is pretty conservative and prohibits
      elimination of repeated double stores to the same field.
      With this CL allocations are changed to "observes initializing or
      transitioning stores".
      This way it is guaranteed that initializing stores to a freshly created
      object or stores that are part of a map transition are not eliminated
      before allocations (that can trigger GC), but allows elimination of
      non-initializing, non-transitioning, unobservable stores in the
      presence of allocations.
      
      Bug: v8:12200
      Change-Id: Ie1419696b9c8cb7c39aecf38d9f08102177b2c0f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295449
      Commit-Queue: Patrick Thier <pthier@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78230}
      863bc2b8
  6. 12 Oct, 2021 1 commit
    • Patrick Thier's avatar
      Revert "[turbofan] Handle Allocations in StoreStoreElimination" · 7796d60e
      Patrick Thier authored
      This reverts commit d87e5f42.
      
      Reason for revert: Causes issues by eliminating stores that can be observed by GC. Flagging stores as "initializing" needs better handling than what was done in this CL.
      
      Original change's description:
      > [turbofan] Handle Allocations in StoreStoreElimination
      >
      > Previously, StoreStoreElimination handled allocations as
      > "can observe anything". This is pretty conservative and prohibits
      > elimination of repeated double stores to the same field.
      > With this CL allocations are changed to "observes initializing stores".
      > This way it is guaranteed that initializing stores to a freshly created
      > object are not eliminated before allocations (that can trigger GC), but
      > allows elimination of non-initializing, unobservable stores in the
      > presence of allocations.
      >
      > Bug: v8:12200
      > Change-Id: I5ef1ca8892a84a3b332e081e2fa6285d0eba9d46
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211585
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#77299}
      
      Bug: v8:12200
      Change-Id: I0f18cbc3e848011f1a998b073b05b3bdbc4e1223
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218158
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Auto-Submit: Patrick Thier <pthier@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Patrick Thier <pthier@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77342}
      7796d60e
  7. 08 Oct, 2021 1 commit
    • Patrick Thier's avatar
      [turbofan] Handle Allocations in StoreStoreElimination · d87e5f42
      Patrick Thier authored
      Previously, StoreStoreElimination handled allocations as
      "can observe anything". This is pretty conservative and prohibits
      elimination of repeated double stores to the same field.
      With this CL allocations are changed to "observes initializing stores".
      This way it is guaranteed that initializing stores to a freshly created
      object are not eliminated before allocations (that can trigger GC), but
      allows elimination of non-initializing, unobservable stores in the
      presence of allocations.
      
      Bug: v8:12200
      Change-Id: I5ef1ca8892a84a3b332e081e2fa6285d0eba9d46
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211585
      Commit-Queue: Patrick Thier <pthier@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77299}
      d87e5f42
  8. 24 Jun, 2021 1 commit
  9. 18 Jun, 2021 1 commit
  10. 21 Apr, 2021 1 commit
  11. 10 Sep, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Implement tier-up (part 3, spawn task & install) · 608018e5
      Jakob Gruber authored
      This is the final part of the tier-up commit series. It implements:
      
      - A prologue in NCI code objects that checks and acts upon the
      optimization marker.
      - Currently, handling is deferred to the InterpreterEntryTrampoline
      but this will change in the future.
      - The lifecycle is otherwise like Ignition-to-Turbofan; the runtime
      profiler marks a function for optimization, the next call to that
      function triggers optimization by calling into runtime, and the
      finished code object is installed both on the JSFunction and the
      optimized code cache.
      - The feedback vector's kOptimizedCodeWeakOrSmiOffset slot is
      currently reused for the mid-to-top tier up.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
      Bug: v8:8888
      Change-Id: Iff50b05ddcc68b25d7ed0f1e0d20af076a1522a0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2361466Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69808}
      608018e5
  12. 28 Jul, 2020 1 commit
  13. 10 Jul, 2020 1 commit
  14. 24 Jun, 2020 1 commit
  15. 17 Sep, 2019 1 commit
    • Jakob Gruber's avatar
      [compiler] Use PersistentMap in store-store elimination · b8127393
      Jakob Gruber authored
      Store-store elimination can potentially allocate many temporary data
      structures, all of which are contained in its so-called temporary
      zone. The zone is 'temporary' in the sense of only existing for the
      lifetime of the StoreStoreEliminationPhase; but all allocated memory
      remains alive until the phase terminates.
      
      Investigation of a pathological case (see the linked bug) showed this
      zone reaching a size of 4GB. The cause in this specific case was the
      UnobservableSet data structure, conceptually an immutable set (i.e.
      each operation creates a full copy). This CL changes the
      UnobservableSet to use a PersistentMap backing store rather than a
      ZoneSet. PersistentMap is intended for exactly this use-case, since
      copies are basically free and updates only change small parts of the
      data structure.
      
      Memory consumption for the linked pathological case drops from 4GB to
      70MB and execution speeds up from 20s to 17s.
      
      Bug: v8:9574
      Change-Id: I902b27f1aa42b88ddd905ee941df24028a68a9bd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1795351
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63819}
      b8127393
  16. 05 Sep, 2019 1 commit
  17. 14 Aug, 2019 2 commits
  18. 12 Aug, 2019 1 commit
    • Santiago Aboy Solanes's avatar
      [turbofan] Remove the size restriction on store store elimination · 8070f963
      Santiago Aboy Solanes authored
      We were only considering eliminating Stores of size Tagged. There doesn't
      appear to be a reason why. This CL enables store store elimination for all
      sizes.
      
      For example, in pointer compression, it means that Compressed values can
      be targeted. In 32 bit versions, it means that doubles can now be targeted.
      
      This is safe under the assumption that every byte of a JS object is only
      ever accessed through one offset. For instance, byte 15 of a given object
      may be accessed using a two-byte read at offset 14, or a four-byte read at
      offset 12, but never both in the same program.
      
      Change-Id: I865d412ed5b4db53a0154cf4da6303c407fdbda7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1746469Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63168}
      8070f963
  19. 17 Jul, 2019 1 commit
  20. 29 Mar, 2019 1 commit
  21. 20 Dec, 2018 1 commit
  22. 20 Sep, 2018 1 commit
  23. 17 Sep, 2018 1 commit
  24. 11 Sep, 2018 1 commit
  25. 15 Jun, 2018 1 commit
  26. 21 Mar, 2018 1 commit
  27. 13 Feb, 2018 1 commit
  28. 02 Jan, 2018 1 commit
  29. 12 Dec, 2017 1 commit
  30. 27 Nov, 2017 1 commit
  31. 25 Sep, 2017 1 commit
  32. 04 Sep, 2017 1 commit
  33. 22 May, 2017 1 commit
  34. 01 Sep, 2016 1 commit
  35. 25 Aug, 2016 1 commit
  36. 16 Aug, 2016 1 commit
  37. 10 Aug, 2016 1 commit
  38. 09 Aug, 2016 2 commits