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. 05 Feb, 2022 1 commit
  5. 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
  6. 16 Dec, 2021 1 commit
  7. 29 Nov, 2021 1 commit
  8. 03 Nov, 2021 1 commit
  9. 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
  10. 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
  11. 26 Oct, 2021 1 commit
  12. 27 Sep, 2021 1 commit
  13. 20 Aug, 2021 1 commit
  14. 16 Apr, 2021 1 commit
  15. 07 Jan, 2021 1 commit
  16. 11 Nov, 2020 1 commit
  17. 26 Oct, 2020 1 commit
  18. 16 Oct, 2020 3 commits
    • Michael Lippautz's avatar
      Reland "cppgc-js: Add snapshot for C++ objects" · 063d56e7
      Michael Lippautz authored
      This reverts commit fba14bde.
      
      Reland fixes:
      - const vector<const string> -> const vector<string>
      
      Original message:
      The following implements a snapshotting algorithm for C++ objects that
      also filters strongly-connected components (SCCs) of only "hidden"
      objects that are not (transitively) referencing any non-hidden
      objects.
      
      C++ objects come in two versions.
      a. Named objects that have been assigned a name through NameProvider.
      b. Unnamed objects, that are potentially hidden if the build
         configuration requires Oilpan to hide such names. Hidden objects have
         their name set to NameProvider::kHiddenName.
      
      The main challenge for the algorithm is to avoid blowing up the final
      object graph with hidden nodes that do not carry information. For that
      reason, the algorithm filters SCCs of only hidden objects, e.g.:
        ...  -> (object) -> (object) -> (hidden) -> (hidden)
      In this case the (hidden) objects are filtered from the graph. The
      trickiest part is maintaining visibility state for objects referencing
      other objects that are currently being processed.
      
      Main algorithm idea (two passes):
      1. First pass marks all non-hidden objects and those that transitively
         reach non-hidden objects as visible. Details:
         - Iterate over all objects.
         - If object is non-hidden mark it as visible and also mark parent
           as visible if needed.
         - If object is hidden, traverse children as DFS to find non-hidden
           objects. Post-order process the objects and mark those objects as
           visible that have child nodes that are visible themselves.
         - Maintain an epoch counter (StateStorage::state_count_) to allow
           deferring the visibility decision to other objects in the same
           SCC. This is similar to the "lowlink" value in Tarjan's algorithm
           for SCC.
         - After the first pass it is guaranteed that all deferred
           visibility decisions can be resolved.
      2. Second pass adds nodes and edges for all visible objects.
         - Upon first checking the visibility state of an object, all deferred
           visibility states are resolved.
      
      For practical reasons, the recursion is transformed into an iteration.
      We do not use plain Tarjan's algorithm to avoid another pass over
      all nodes to create SCCs.
      
      Follow ups:
      1. Adding wrapper nodes for cpp objects that are wrappables for V8
         wrappers.
      2. Adding detachedness information.
      
      Bug: chromium:1056170
      Change-Id: Ib47df5c912c57d644d052f209276e9d926cece0f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2480362
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70577}
      063d56e7
    • Maya Lekova's avatar
      Revert "cppgc-js: Add snapshot for C++ objects" · fba14bde
      Maya Lekova authored
      This reverts commit 02849fd9.
      
      Reason for revert: Breaks Win64 MSVC bot and closes the tree - https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/15416
      
      Original change's description:
      > cppgc-js: Add snapshot for C++ objects
      >
      > The following implements a snapshotting algorithm for C++ objects that
      > also filters strongly-connected components (SCCs) of only "hidden"
      > objects that are not (transitively) referencing any non-hidden
      > objects.
      >
      > C++ objects come in two versions.
      > a. Named objects that have been assigned a name through NameProvider.
      > b. Unnamed objects, that are potentially hidden if the build
      >    configuration requires Oilpan to hide such names. Hidden objects have
      >    their name set to NameProvider::kHiddenName.
      >
      > The main challenge for the algorithm is to avoid blowing up the final
      > object graph with hidden nodes that do not carry information. For that
      > reason, the algorithm filters SCCs of only hidden objects, e.g.:
      >   ...  -> (object) -> (object) -> (hidden) -> (hidden)
      > In this case the (hidden) objects are filtered from the graph. The
      > trickiest part is maintaining visibility state for objects referencing
      > other objects that are currently being processed.
      >
      > Main algorithm idea (two passes):
      > 1. First pass marks all non-hidden objects and those that transitively
      >    reach non-hidden objects as visible. Details:
      >    - Iterate over all objects.
      >    - If object is non-hidden mark it as visible and also mark parent
      >      as visible if needed.
      >    - If object is hidden, traverse children as DFS to find non-hidden
      >      objects. Post-order process the objects and mark those objects as
      >      visible that have child nodes that are visible themselves.
      >    - Maintain an epoch counter (StateStorage::state_count_) to allow
      >      deferring the visibility decision to other objects in the same
      >      SCC. This is similar to the "lowlink" value in Tarjan's algorithm
      >      for SCC.
      >    - After the first pass it is guaranteed that all deferred
      >      visibility decisions can be resolved.
      > 2. Second pass adds nodes and edges for all visible objects.
      >    - Upon first checking the visibility state of an object, all deferred
      >      visibility states are resolved.
      >
      > For practical reasons, the recursion is transformed into an iteration.
      > We do not use plain Tarjan's algorithm to avoid another pass over
      > all nodes to create SCCs.
      >
      > Follow ups:
      > 1. Adding wrapper nodes for cpp objects that are wrappables for V8
      >    wrappers.
      > 2. Adding detachedness information.
      >
      > Change-Id: I6e127d2c6d65e77defe08e39295a2594f463b962
      > Bug: chromium:1056170
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467854
      > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70567}
      
      TBR=ulan@chromium.org,mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org
      
      Change-Id: I64a2cf2259bdaed81f6e0f92bdcc7a1f0df4d197
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:1056170
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479471Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70571}
      fba14bde
    • Michael Lippautz's avatar
      cppgc-js: Add snapshot for C++ objects · 02849fd9
      Michael Lippautz authored
      The following implements a snapshotting algorithm for C++ objects that
      also filters strongly-connected components (SCCs) of only "hidden"
      objects that are not (transitively) referencing any non-hidden
      objects.
      
      C++ objects come in two versions.
      a. Named objects that have been assigned a name through NameProvider.
      b. Unnamed objects, that are potentially hidden if the build
         configuration requires Oilpan to hide such names. Hidden objects have
         their name set to NameProvider::kHiddenName.
      
      The main challenge for the algorithm is to avoid blowing up the final
      object graph with hidden nodes that do not carry information. For that
      reason, the algorithm filters SCCs of only hidden objects, e.g.:
        ...  -> (object) -> (object) -> (hidden) -> (hidden)
      In this case the (hidden) objects are filtered from the graph. The
      trickiest part is maintaining visibility state for objects referencing
      other objects that are currently being processed.
      
      Main algorithm idea (two passes):
      1. First pass marks all non-hidden objects and those that transitively
         reach non-hidden objects as visible. Details:
         - Iterate over all objects.
         - If object is non-hidden mark it as visible and also mark parent
           as visible if needed.
         - If object is hidden, traverse children as DFS to find non-hidden
           objects. Post-order process the objects and mark those objects as
           visible that have child nodes that are visible themselves.
         - Maintain an epoch counter (StateStorage::state_count_) to allow
           deferring the visibility decision to other objects in the same
           SCC. This is similar to the "lowlink" value in Tarjan's algorithm
           for SCC.
         - After the first pass it is guaranteed that all deferred
           visibility decisions can be resolved.
      2. Second pass adds nodes and edges for all visible objects.
         - Upon first checking the visibility state of an object, all deferred
           visibility states are resolved.
      
      For practical reasons, the recursion is transformed into an iteration.
      We do not use plain Tarjan's algorithm to avoid another pass over
      all nodes to create SCCs.
      
      Follow ups:
      1. Adding wrapper nodes for cpp objects that are wrappables for V8
         wrappers.
      2. Adding detachedness information.
      
      Change-Id: I6e127d2c6d65e77defe08e39295a2594f463b962
      Bug: chromium:1056170
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467854
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70567}
      02849fd9
  19. 18 Sep, 2020 1 commit
  20. 09 Sep, 2020 1 commit
  21. 18 Dec, 2019 1 commit
  22. 15 Nov, 2019 1 commit
  23. 13 Sep, 2019 1 commit
  24. 09 Aug, 2019 1 commit
  25. 29 Jul, 2019 3 commits
    • Clemens Hammacher's avatar
      Reland "[utils] Make BitField final" · 0cabc6a0
      Clemens Hammacher authored
      This is a reland of 658ff200
      
      Original change's description:
      > [utils] Make BitField final
      > 
      > We have hundreds of classes that derive from {BitField} without adding
      > any functionality. This CL switches all such occurrences to 'using'
      > declarations instead.
      > 
      > Before:
      >   class MyBitField : public BitField<int, 6, 4, MyEnum> {};
      > After:
      >   using MyBitField = BitField<int, 6, 4, MyEnum>;
      > 
      > This might reduce compilation time by reducing the number of existing
      > classes.
      > 
      > The old pattern is forbidden now by making {BitField} final.
      > 
      > R=yangguo@chromium.org
      > 
      > Bug: v8:9396, v8:7629
      > Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62956}
      
      Bug: v8:9396, v8:7629
      Change-Id: Ic68541af9d1e8d0340691970922f282b24a9767f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724379Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62959}
      0cabc6a0
    • Clemens Hammacher's avatar
      Revert "[utils] Make BitField final" · 753a07db
      Clemens Hammacher authored
      This reverts commit 658ff200.
      
      Reason for revert: Fails no-i18n bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/27826
      
      Original change's description:
      > [utils] Make BitField final
      > 
      > We have hundreds of classes that derive from {BitField} without adding
      > any functionality. This CL switches all such occurrences to 'using'
      > declarations instead.
      > 
      > Before:
      >   class MyBitField : public BitField<int, 6, 4, MyEnum> {};
      > After:
      >   using MyBitField = BitField<int, 6, 4, MyEnum>;
      > 
      > This might reduce compilation time by reducing the number of existing
      > classes.
      > 
      > The old pattern is forbidden now by making {BitField} final.
      > 
      > R=​yangguo@chromium.org
      > 
      > Bug: v8:9396, v8:7629
      > Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62956}
      
      TBR=yangguo@chromium.org,clemensh@chromium.org
      
      Change-Id: I50234a09c77aa89fdcf1e01c2497cc08d3ac79a8
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9396, v8:7629
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724377Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62958}
      753a07db
    • Clemens Hammacher's avatar
      [utils] Make BitField final · 658ff200
      Clemens Hammacher authored
      We have hundreds of classes that derive from {BitField} without adding
      any functionality. This CL switches all such occurrences to 'using'
      declarations instead.
      
      Before:
        class MyBitField : public BitField<int, 6, 4, MyEnum> {};
      After:
        using MyBitField = BitField<int, 6, 4, MyEnum>;
      
      This might reduce compilation time by reducing the number of existing
      classes.
      
      The old pattern is forbidden now by making {BitField} final.
      
      R=yangguo@chromium.org
      
      Bug: v8:9396, v8:7629
      Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62956}
      658ff200
  26. 17 Jun, 2019 1 commit
  27. 27 May, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Replace simple typedefs by using · a335f2ae
      Clemens Hammacher authored
      This replaces all typedefs that define types and not functions by the
      equivalent "using" declaration.
      
      This was done mostly automatically using this command:
      ag -l '\btypedef\b' src test | xargs -L1 \
           perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg'
      
      Patchset 2 then adds some manual changes for typedefs for pointer types,
      where the regular expression did not match.
      
      R=mstarzinger@chromium.org
      TBR=yangguo@chromium.org, jarin@chromium.org
      
      Bug: v8:9183
      Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61849}
      a335f2ae
  28. 24 May, 2019 1 commit
  29. 23 May, 2019 1 commit
  30. 21 May, 2019 1 commit
  31. 27 Mar, 2019 1 commit
  32. 24 Jan, 2019 1 commit
  33. 08 Jan, 2019 1 commit
  34. 26 Dec, 2018 1 commit
  35. 20 Dec, 2018 1 commit