1. 23 Jun, 2020 1 commit
  2. 09 Jun, 2020 1 commit
  3. 30 Apr, 2020 1 commit
  4. 21 Feb, 2020 1 commit
  5. 05 Feb, 2020 1 commit
    • Michael Lippautz's avatar
      Reland "heap: Delay completing marking" · 562c15d6
      Michael Lippautz authored
      Delay completing marking (and thus the atomic GC pause) during JS
      executions, increasing the chance to finalize the garbage collection
      from a task. This is beneficial as it avoids stack scanning which is
      expensive and can keep alive outdated objects in case of unified heap.
      
      Completing will be delayed at most by some overshoot factor (10%).
      
      In addition, the GC keeps the weighted average of previously recorded
      time to incremental marking task invocations and bails out if the
      task is expected to arrive too late.
      
      Reland: Do not schedule a delayed task when marking has already been
      finalized.
      
      This reverts commit 1775684e.
      
      Bug: chromium:1044630, v8:10178
      Change-Id: Ic46e9504ce7c200bd1d37ee8d0190fb8727a3f96
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037436Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66137}
      562c15d6
  6. 04 Feb, 2020 2 commits
    • Michael Achenbach's avatar
      Revert "heap: Delay completing marking" · 1775684e
      Michael Achenbach authored
      This reverts commit 02e57873.
      
      Reason for revert: High flakiness and broken GPU builders. See:
      https://crbug.com/v8/10178
      (speculative revert)
      
      Original change's description:
      > heap: Delay completing marking
      > 
      > Delay completing marking (and thus the atomic GC pause) during JS
      > executions, increasing the chance to finalize the garbage collection
      > from a task. This is beneficial as it avoids stack scanning which is
      > expensive and can keep alive outdated objects in case of unified heap.
      > 
      > Completing will be delayed at most by some overshoot factor (10%).
      > 
      > In addition, the GC keeps the weighted average of previously recorded
      > time to incremental marking task invocations and bails out if the
      > task is expected to arrive too late.
      > 
      > Bug: chromium:1044630
      > Change-Id: I10e63e6aaa88d8488d4415f311016dce2b4e62a2
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030906
      > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66107}
      
      TBR=ulan@chromium.org,hpayer@chromium.org,mlippautz@chromium.org
      
      Change-Id: I0cd3f1189d0f83754350d5bdaaf82cb3c4d402c8
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:1044630, v8:10178
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037434Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66120}
      1775684e
    • Michael Lippautz's avatar
      heap: Delay completing marking · 02e57873
      Michael Lippautz authored
      Delay completing marking (and thus the atomic GC pause) during JS
      executions, increasing the chance to finalize the garbage collection
      from a task. This is beneficial as it avoids stack scanning which is
      expensive and can keep alive outdated objects in case of unified heap.
      
      Completing will be delayed at most by some overshoot factor (10%).
      
      In addition, the GC keeps the weighted average of previously recorded
      time to incremental marking task invocations and bails out if the
      task is expected to arrive too late.
      
      Bug: chromium:1044630
      Change-Id: I10e63e6aaa88d8488d4415f311016dce2b4e62a2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030906
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66107}
      02e57873
  7. 24 Jan, 2020 1 commit
  8. 05 Nov, 2019 1 commit
  9. 29 Aug, 2019 1 commit
  10. 21 Aug, 2019 1 commit
  11. 29 Jul, 2019 1 commit
  12. 24 Jun, 2019 2 commits
  13. 17 Jun, 2019 1 commit
  14. 13 Jun, 2019 1 commit
    • Darius Mercadier's avatar
      Add FLAG_trace_gc_freelists and _verbose version · f4ebc674
      Darius Mercadier authored
      With this flag enabled, some statistics about the oldspace's freelists
      (and free/used spaced in general) are printed before and after each
      major garbage collection.
      
      It is useful to get some intuition about fragmentation and debug
      freelists. (This flag helped me track down the issues fixed by CLs
      1647162 and 1648476)
      
      Additionally, the verbose version (FLAG_trace_gc_freelists_verbose)
      prints the freelists of each page of old_space.
      
      Bug: v8:9329
      Change-Id: Ifa80426bf9d97ac9950459154507a585b039326d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655302
      Commit-Queue: Darius Mercadier <dmercadier@google.com>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62150}
      f4ebc674
  15. 31 May, 2019 1 commit
  16. 22 May, 2019 3 commits
  17. 21 May, 2019 3 commits
    • Michael Lippautz's avatar
      Reland "[heap] Add global memory controller" · dac86be2
      Michael Lippautz authored
      Provide a global memory controller used to compute limits for combined
      on-heap and embedder memory. The global controller uses the same
      mechanism (gc speed, mutator speed) and growing factors as the regular
      on-heap controller.
      
      Rely on V8's mechanisms for configured state that stops shrinking the
      limit.
      
      This reverts commit 5e043f27.
      
      Tbr: ulan@chromium.org
      Bug: chromium:948807
      Change-Id: Id4f94e7dcb458d1d0d2f872194f8f3ea0959a73f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1622968Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61715}
      dac86be2
    • Michael Lippautz's avatar
      Revert "[heap] Add global memory controller" · 5e043f27
      Michael Lippautz authored
      This reverts commit cfe281f3.
      
      Reason for revert: Fails on gcc bots
      
      Original change's description:
      > [heap] Add global memory controller
      > 
      > Provide a global memory controller used to compute limits for combined
      > on-heap and embedder memory. The global controller uses the same
      > mechanism (gc speed, mutator speed) and growing factors as the regular
      > on-heap controller.
      > 
      > Rely on V8's mechanisms for configured state that stops shrinking the
      > limit.
      > 
      > Bug: chromium:948807
      > Change-Id: I3283a2c28e6ab889f8d2ad85c9b67b8f234b9900
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619762
      > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Hannes Payer <hpayer@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61712}
      
      TBR=ulan@chromium.org,hpayer@chromium.org,mlippautz@chromium.org,bikineev@chromium.org
      
      Change-Id: I503d5a1436eb9156556b5bca852d2b2f9da2446f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:948807
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1622967Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61713}
      5e043f27
    • Michael Lippautz's avatar
      [heap] Add global memory controller · cfe281f3
      Michael Lippautz authored
      Provide a global memory controller used to compute limits for combined
      on-heap and embedder memory. The global controller uses the same
      mechanism (gc speed, mutator speed) and growing factors as the regular
      on-heap controller.
      
      Rely on V8's mechanisms for configured state that stops shrinking the
      limit.
      
      Bug: chromium:948807
      Change-Id: I3283a2c28e6ab889f8d2ad85c9b67b8f234b9900
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619762
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61712}
      cfe281f3
  18. 20 May, 2019 2 commits
    • Pierre Langlois's avatar
      [tracing] Emit heap statistics at every GC. · 990084ba
      Pierre Langlois authored
      When the 'disabled-by-default-v8.gc' category is enabled, emit an instant event
      with heap statistics after every GC. The data that's emitted is the same as what
      the V8 API gives you with `GetHeapStatistics()` and `GetHeapSpaceStatistics()`.
      
      We generate JSON with the following format:
      
      ```
      {
       "isolate": "0x55dd5cf03b50",
       "id": 1,
       "time_ms": 42.619,
      
       "total_heap_size": 3981312,
       "total_heap_size_executable": 573440,
       "total_physical_size": 2820440,
       "total_available_size": 2195254440,
      
       "used_heap_size": 1799616,
       "heap_size_limit": 2197815296,
       "malloced_memory": 251024,
       "external_memory": 2981,
       "peak_malloced_memory": 589280,
      
       "spaces": [
         {
           "name": "read_only_space",
           "size": 262144,
           "used_size": 32568,
           "available_size": 229256,
           "physical_size": 32888
         },
         {
           "name": "new_space",
           "size": 2097152,
           "used_size": 903392,
           "available_size": 143904,
           "physical_size": 1856136
         },
         ...
       ]
      }
      ```
      
      Bug: v8:9186
      Change-Id: I0d07aa37b65d45778d6b47dbe6e07a9dd25d1097
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619763Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
      Cr-Commit-Position: refs/heads/master@{#61667}
      990084ba
    • Yang Guo's avatar
      Reland "Move logging and diagnostics related source files" · bf372a73
      Yang Guo authored
      TBR=verwaest@chromium.org,rmcilroy@chromium.org
      NOTREECHECKS=true
      NOPRESUBMIT=true
      
      Bug: v8:9247
      Change-Id: I9ddfb6e56ca8e47c4ac186a8df5f442d26420a69
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617661
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61642}
      bf372a73
  19. 17 May, 2019 2 commits
  20. 15 May, 2019 1 commit
  21. 29 Apr, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Use Vector::begin instead of Vector::start · 4b0f9c85
      Clemens Hammacher authored
      Our {Vector} template provides both {start} and {begin} methods. They
      return exactly the same value. Since the {begin} method is needed for
      iteration, and is also what standard containers provide, this CL
      switches all uses of the {start} method to use {begin} instead.
      
      Patchset 1 was auto-generated by using this clang AST matcher:
          callExpr(
              callee(
                cxxMethodDecl(
                  hasName("start"),
                  ofClass(hasName("v8::internal::Vector")))
              ),
              argumentCountIs(0))
      
      Patchset 2 was created by running clang-format. Patchset 3 then
      removes the now unused {Vector::start} method.
      
      R=jkummerow@chromium.org
      TBR=mstarzinger@chromium.org,yangguo@chromium.org,verwaest@chromium.org
      
      Bug: v8:9183
      Change-Id: Id9f01c92870872556e2bb3f6d5667463b0e3e5c6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587381Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61081}
      4b0f9c85
  22. 11 Apr, 2019 1 commit
  23. 02 Apr, 2019 1 commit
  24. 07 Mar, 2019 1 commit
  25. 07 Feb, 2019 2 commits
  26. 05 Feb, 2019 1 commit
  27. 18 Jan, 2019 1 commit
    • Ulan Degenbaev's avatar
      Reland "[heap] Remove bailout marking worklist." · 8b3fbe1d
      Ulan Degenbaev authored
      This reverts commit 13e07389.
      
      Original change's description:
      > [heap] Remove bailout marking worklist.
      >
      > The concurrent marker can now process all objects.
      > This patch also eagerly visits the objects that undergo layout
      > changes. This is because previously such objects were pushed
      > onto the bailout worklist, which is gone now.
      > To preserve the incremental step accounting, the patch introduces
      > a new GC tracer scope called MC_INCREMENTAL_LAYOUT_CHANGE.
      >
      > Bug: v8:8486
      > Change-Id: Ic1c2f0d4e2ac0602fc945f3258af9624247bd65f
      > Reviewed-on: https://chromium-review.googlesource.com/c/1386486
      > Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58712}
      
      Change-Id: I85c99837819f6971c248198bd51ad40eebdb4fac
      Reviewed-on: https://chromium-review.googlesource.com/c/1417595Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58913}
      8b3fbe1d
  28. 14 Jan, 2019 1 commit
    • Ulan Degenbaev's avatar
      Revert "[heap] Remove bailout marking worklist." · 13e07389
      Ulan Degenbaev authored
      This reverts commit 68a8bdd8.
      
      Reason for revert: memory regression: crbug.com/921239
      
      Original change's description:
      > [heap] Remove bailout marking worklist.
      > 
      > The concurrent marker can now process all objects.
      > This patch also eagerly visits the objects that undergo layout
      > changes. This is because previously such objects were pushed
      > onto the bailout worklist, which is gone now.
      > To preserve the incremental step accounting, the patch introduces
      > a new GC tracer scope called MC_INCREMENTAL_LAYOUT_CHANGE.
      > 
      > Bug: v8:8486
      > Change-Id: Ic1c2f0d4e2ac0602fc945f3258af9624247bd65f
      > Reviewed-on: https://chromium-review.googlesource.com/c/1386486
      > Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58712}
      
      TBR=ulan@chromium.org,mlippautz@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:8486, chromium:921239
      Change-Id: I1f851b948f4ce403316e469999f0b16e8dfdb62d
      Reviewed-on: https://chromium-review.googlesource.com/c/1408990
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58787}
      13e07389
  29. 10 Jan, 2019 1 commit
    • Ulan Degenbaev's avatar
      [heap] Remove bailout marking worklist. · 68a8bdd8
      Ulan Degenbaev authored
      The concurrent marker can now process all objects.
      This patch also eagerly visits the objects that undergo layout
      changes. This is because previously such objects were pushed
      onto the bailout worklist, which is gone now.
      To preserve the incremental step accounting, the patch introduces
      a new GC tracer scope called MC_INCREMENTAL_LAYOUT_CHANGE.
      
      Bug: v8:8486
      Change-Id: Ic1c2f0d4e2ac0602fc945f3258af9624247bd65f
      Reviewed-on: https://chromium-review.googlesource.com/c/1386486
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58712}
      68a8bdd8
  30. 26 Nov, 2018 1 commit
    • Marja Hölttä's avatar
      [iwyu] Include heap-inl.h less. · 0453d418
      Marja Hölttä authored
      - Remove heap-inl.h includes from places where it looked unnecessary. (This is a
        non-scientific approach, because it's probably pulled in indirectly anyway.)
      
      - Annotate places which include heap-inl.h because they need heap/ internals.
      
      - ACCESSORS legitimately needs heap-inl.h because of Heap::FromWritableHeapObject.
      
      - Add includes to heap/heap-write-barrier(-inl).h
      
      - A bunch of IWYU fixes discovered when working on this CL (includes which were
        missing because heap-inl.h pulls them in indirectly).
      
      BUG=v8:7490,v8:8238,v8:8499
      
      Change-Id: I00f9a74d430f13d7c080dca77a92b03bcca7ef96
      Reviewed-on: https://chromium-review.googlesource.com/c/1349241Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57814}
      0453d418
  31. 20 Nov, 2018 1 commit