1. 06 May, 2022 1 commit
  2. 22 Apr, 2022 1 commit
  3. 06 Apr, 2022 1 commit
    • Seth Brenith's avatar
      Categorize more objects as kCode in heap snapshots · 4e45eed9
      Seth Brenith authored
      Currently, the category named “(compiled code)” contains Code,
      SharedFunctionInfo, and Script objects. However, there are various other
      object types that are allocated per script function, such as
      BytecodeArray and FeedbackVector. There are also plain FixedArrays which
      are used for function-specific data such as polymorphic feedback and
      code deoptimization data. I propose we move all of this to the
      “(compiled code)” category, because this memory usage is related to the
      number of functions in the script, the size of those functions, and/or
      the number of times those functions have been called.
      
      Bug: v8:12769
      Change-Id: Ib5e0265a9ef88063596c17419f5b65f683156c52
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3569876Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#79827}
      4e45eed9
  4. 04 Mar, 2022 1 commit
  5. 02 Mar, 2022 1 commit
  6. 05 Feb, 2022 1 commit
  7. 04 Feb, 2022 1 commit
    • Seth Brenith's avatar
      Add verifier for retaining paths in heap snapshots · d937a0bb
      Seth Brenith authored
      The web app owner who notified me about bugs v8:12112 and v8:12126 asked
      me a reasonable question: "how am I ever supposed to trust the retaining
      paths in the devtools, if the heap snapshot is generated by a different
      component than the actual marking code?". This change is my attempt to
      answer that question. If verification is enabled, the heap snapshot
      generator will visit each heap object with a realistic marking visitor
      to find all references from that object. It will then check that those
      references match the HeapGraphEdges in the snapshot.
      
      I also considered the idea that we could collect retaining information
      during the last GC cycle before taking the heap snapshot, or during an
      extra GC cycle immediately after. However, running the full GC provides
      the embedder with the opportunity to run arbitrary code (including JS)
      both before and after PerformGarbageCollection, so there is no clear
      guarantee that the heap state during the snapshot actually matches the
      heap state during marking.
      
      Bug: v8:12112, v8:12126
      Change-Id: Id29e75ecf9eee19e35daedbdb4a3e1df64785380
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3299590Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#78952}
      d937a0bb
  8. 17 Jan, 2022 1 commit
    • Victor Gomes's avatar
      Reland "[runtime] Adds LocalNameIterator" · 4ebc9b7b
      Victor Gomes authored
      This is a reland of f605d778
      
      Adds a GC safe (using handles) and unsafe versions of the iterator.
      
      V8HeapExplorer needs an unsafe one, since it does not allow the
      creation of handles.
      
      Original change's description:
      > [runtime] Adds LocalNameIterator
      >
      > ScopeInfo will contain either inlined (array) local names or
      > a hash table (names => index) containing the local names.
      >
      > We abstract iteration with LocalNameIterator and remove
      > ContextLocalName since accessing a local name by index in
      > the hash table would be expensive.
      >
      > This CL only implements the iterator for the array.
      >
      > Bug: v8:12315
      > Change-Id: I2c62802652fca1cf47815ce8768a3f7487f2c39f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386603
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78623}
      
      Bug: v8:12315
      Change-Id: I6288a08b9c342cd3a9cabcb621c40bb44c08c9c4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3394706Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78653}
      4ebc9b7b
  9. 14 Jan, 2022 2 commits
    • Leszek Swirski's avatar
      Revert "[runtime] Adds LocalNameIterator" · 1e42a27f
      Leszek Swirski authored
      This reverts commit f605d778.
      
      Reason for revert: Segfaults: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/36908/overview
      
      Original change's description:
      > [runtime] Adds LocalNameIterator
      >
      > ScopeInfo will contain either inlined (array) local names or
      > a hash table (names => index) containing the local names.
      >
      > We abstract iteration with LocalNameIterator and remove
      > ContextLocalName since accessing a local name by index in
      > the hash table would be expensive.
      >
      > This CL only implements the iterator for the array.
      >
      > Bug: v8:12315
      > Change-Id: I2c62802652fca1cf47815ce8768a3f7487f2c39f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386603
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78623}
      
      Bug: v8:12315
      Change-Id: Ibabe231f4357a3dd02d24b89847d579b83867a1a
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386385
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Owners-Override: Leszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78625}
      1e42a27f
    • Victor Gomes's avatar
      [runtime] Adds LocalNameIterator · f605d778
      Victor Gomes authored
      ScopeInfo will contain either inlined (array) local names or
      a hash table (names => index) containing the local names.
      
      We abstract iteration with LocalNameIterator and remove
      ContextLocalName since accessing a local name by index in
      the hash table would be expensive.
      
      This CL only implements the iterator for the array.
      
      Bug: v8:12315
      Change-Id: I2c62802652fca1cf47815ce8768a3f7487f2c39f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386603Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78623}
      f605d778
  10. 16 Dec, 2021 1 commit
  11. 06 Dec, 2021 1 commit
  12. 30 Nov, 2021 2 commits
  13. 29 Nov, 2021 1 commit
  14. 15 Nov, 2021 1 commit
  15. 09 Nov, 2021 1 commit
  16. 08 Nov, 2021 1 commit
  17. 03 Nov, 2021 1 commit
  18. 29 Oct, 2021 1 commit
    • Kim-Anh Tran's avatar
      Reland "[heap-snapshot] Preventing overflow in progress counter" · 4d937998
      Kim-Anh Tran authored
      This is a reland of 0e006a15
      Difference:
       * progress_total_ and progress_counter_ access are guarded by
         checking if control_ is set. If not, we do not report any progress
         and both are not set.
      
      Original change's description:
      > [heap-snapshot] Preventing overflow in progress counter
      >
      > This prevents an overflow to happen in the heap snapshot generator.
      > Furthermore it changes the relation of progress_counter_ and
      > progress_total_ to always adhere to:
      > * progress_counter_ <= progress_total_,
      > * if: progress_counter_ == progress_total_, then it is done.
      >
      > With this change, if progress_counter_ happens to be bigger
      > than progress_total_ (latter is an estimate), it will continue
      > to report the same progress (<100%) until it is done. Before,
      > it would repeatedly report 100% until it is done.
      >
      > Fixed: chromium:1246860
      > Change-Id: Iffd3f52355632f2b35abdbb3752912ba7b8bd821
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3250310
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#77589}
      
      Bug: chromium:1246860
      Change-Id: I7522c1fe011954dd18828bdef507abe3e0237d42
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3251170Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77608}
      4d937998
  19. 28 Oct, 2021 2 commits
    • Clemens Backes's avatar
      Revert "[heap-snapshot] Preventing overflow in progress counter" · 5cbd1eed
      Clemens Backes authored
      This reverts commit 0e006a15.
      
      Reason for revert: MSan failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/41031/overview
      
      Original change's description:
      > [heap-snapshot] Preventing overflow in progress counter
      >
      > This prevents an overflow to happen in the heap snapshot generator.
      > Furthermore it changes the relation of progress_counter_ and
      > progress_total_ to always adhere to:
      > * progress_counter_ <= progress_total_,
      > * if: progress_counter_ == progress_total_, then it is done.
      >
      > With this change, if progress_counter_ happens to be bigger
      > than progress_total_ (latter is an estimate), it will continue
      > to report the same progress (<100%) until it is done. Before,
      > it would repeatedly report 100% until it is done.
      >
      > Fixed: chromium:1246860
      > Change-Id: Iffd3f52355632f2b35abdbb3752912ba7b8bd821
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3250310
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#77589}
      
      Change-Id: I81e8bb563a48ce6b877e83e30a5f426bef0bb58d
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3250901
      Auto-Submit: Clemens Backes <clemensb@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Owners-Override: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77590}
      5cbd1eed
    • Kim-Anh Tran's avatar
      [heap-snapshot] Preventing overflow in progress counter · 0e006a15
      Kim-Anh Tran authored
      This prevents an overflow to happen in the heap snapshot generator.
      Furthermore it changes the relation of progress_counter_ and
      progress_total_ to always adhere to:
      * progress_counter_ <= progress_total_,
      * if: progress_counter_ == progress_total_, then it is done.
      
      With this change, if progress_counter_ happens to be bigger
      than progress_total_ (latter is an estimate), it will continue
      to report the same progress (<100%) until it is done. Before,
      it would repeatedly report 100% until it is done.
      
      Fixed: chromium:1246860
      Change-Id: Iffd3f52355632f2b35abdbb3752912ba7b8bd821
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3250310Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77589}
      0e006a15
  20. 26 Oct, 2021 1 commit
  21. 19 Oct, 2021 1 commit
  22. 12 Oct, 2021 1 commit
  23. 11 Oct, 2021 1 commit
  24. 29 Sep, 2021 1 commit
  25. 28 Sep, 2021 1 commit
  26. 27 Sep, 2021 1 commit
  27. 06 Sep, 2021 1 commit
  28. 20 Aug, 2021 1 commit
  29. 18 Aug, 2021 1 commit
    • Seth Brenith's avatar
      Avoid reporting incorrect retaining paths in heap snapshots · 53a527f6
      Seth Brenith authored
      The heap snapshot view in the dev tools reports a lot of incorrect
      retaining paths involving weak references from FeedbackVectors. To fix,
      when IndexedReferencesExtractor encounters a weak reference, it should
      record a weak reference rather than a hidden reference. This way, the
      forward reference is still visible when exploring in the summary view,
      but weak references aren't reported as retainers.
      
      Bug: v8:12112
      Change-Id: Ib3bafc49482fb4f515877a90bae8707483d0a7a2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3101266Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#76364}
      53a527f6
  30. 20 Jul, 2021 1 commit
  31. 19 Jul, 2021 1 commit
  32. 15 Jul, 2021 1 commit
  33. 01 Jul, 2021 1 commit
  34. 22 Jun, 2021 1 commit
  35. 21 Jun, 2021 1 commit
  36. 18 Jun, 2021 1 commit
  37. 20 May, 2021 1 commit