1. 21 Aug, 2020 1 commit
    • Ulan Degenbaev's avatar
      Reland "[heap] Add concurrent marking write barrier" · e0ad32ce
      Ulan Degenbaev authored
      This is a reland of 1dd7f3a9
      
      Original change's description:
      > [heap] Add concurrent marking write barrier
      > 
      > A LocalHeap creates and owns an instance of MarkingBarrier. A pointer to
      > the marking barrier is set to a thread_local variable for a quick access.
      > 
      > WriteBarrier::MarkingSlow fetches the thread_local variable and invokes
      > the write barrier if it is set. Otherwise, it invokes the main thread
      > heap()->marking_barrier().
      > 
      > Each marking barrier has its own local marking worklist that is
      > published during scavenge (for updating pointers) and at finalization
      > of incremental marking.
      > 
      > Typed-slot recording does not work yet because it is not thread-safe.
      > It will be fixed in a subsequent CL.
      > 
      > Bug: v8:10315
      > Change-Id: I221a906436cd91e7405a253ce0eb06cf68046f2c
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2354809
      > Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69448}
      
      Bug: v8:10315
      Change-Id: I155bb0aadd53a5333672fb085b33d8da86f3f336
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2364509Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69517}
      e0ad32ce
  2. 20 Aug, 2020 1 commit
    • Omer Katz's avatar
      cppgc: Add marked bytes deadline · 808a775f
      Omer Katz authored
      This CL adds a bytes based deadline to draining of worklist.
      The time based deadline is also kept because:
      1) Unified heap can't transition to bytes-based deadlines yet.
      2) Unified heap with concurrent marking needs to flush v8 references
         which don't count as marked_bytes and can cause very long incremental
         pauses.
      
      Bug: chromium:1056170
      Change-Id: I5ab57754e7ff0b5821f3acb76e1e6f59fc9d68b8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2299374Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69506}
      808a775f
  3. 18 Aug, 2020 2 commits
    • Maya Lekova's avatar
      Revert "[heap] Add concurrent marking write barrier" · 2f45e41a
      Maya Lekova authored
      This reverts commit 1dd7f3a9.
      
      Reason for revert: Breaks TSAN - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/32846?
      
      Original change's description:
      > [heap] Add concurrent marking write barrier
      > 
      > A LocalHeap creates and owns an instance of MarkingBarrier. A pointer to
      > the marking barrier is set to a thread_local variable for a quick access.
      > 
      > WriteBarrier::MarkingSlow fetches the thread_local variable and invokes
      > the write barrier if it is set. Otherwise, it invokes the main thread
      > heap()->marking_barrier().
      > 
      > Each marking barrier has its own local marking worklist that is
      > published during scavenge (for updating pointers) and at finalization
      > of incremental marking.
      > 
      > Typed-slot recording does not work yet because it is not thread-safe.
      > It will be fixed in a subsequent CL.
      > 
      > Bug: v8:10315
      > Change-Id: I221a906436cd91e7405a253ce0eb06cf68046f2c
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2354809
      > Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69448}
      
      TBR=ulan@chromium.org,dinfuehr@chromium.org
      
      Change-Id: I9719d565aaa313cd23f5e759dcef1246f475eb46
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10315
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362689Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69451}
      2f45e41a
    • Ulan Degenbaev's avatar
      [heap] Add concurrent marking write barrier · 1dd7f3a9
      Ulan Degenbaev authored
      A LocalHeap creates and owns an instance of MarkingBarrier. A pointer to
      the marking barrier is set to a thread_local variable for a quick access.
      
      WriteBarrier::MarkingSlow fetches the thread_local variable and invokes
      the write barrier if it is set. Otherwise, it invokes the main thread
      heap()->marking_barrier().
      
      Each marking barrier has its own local marking worklist that is
      published during scavenge (for updating pointers) and at finalization
      of incremental marking.
      
      Typed-slot recording does not work yet because it is not thread-safe.
      It will be fixed in a subsequent CL.
      
      Bug: v8:10315
      Change-Id: I221a906436cd91e7405a253ce0eb06cf68046f2c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2354809
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69448}
      1dd7f3a9
  4. 11 Aug, 2020 1 commit
    • Ulan Degenbaev's avatar
      [heap] Split marking worklist into global worklist and local worklists · 28133adc
      Ulan Degenbaev authored
      This is the first step in refactoring Worklist to allow arbitrary
      number of local worklists with private segments:
      - Introduce MarkingWorklistImpl<> which will eventually replace
        (and will be renamed to) Worklist.
      - MarkingWorklistImpl<> owns the global pool of segments but does not
        keep track of private segments.
      - MarkingWorklistImpl<>::Local owns private segments and can be
        constructed dynamically on background threads.
      - Rename the existing MarkingWorklistsHolder to MarkingWorklists.
      - Rename the existing MarkingWorklists to MarkingWorklists::Local.
      - Rename the existing marking_workists_holder to marking_worklists.
      - Rename the existing marking_worklists to local_marking_worklists.
      
      Design doc: https://bit.ly/2XMtjLi
      Bug: v8:10315
      
      Change-Id: I9da34883ad34f4572fccd40c51e51eaf50c617bc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2343330Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69330}
      28133adc
  5. 07 Jul, 2020 1 commit
  6. 28 May, 2020 1 commit
  7. 26 May, 2020 2 commits
  8. 15 May, 2020 1 commit
  9. 12 May, 2020 2 commits
  10. 11 May, 2020 2 commits
  11. 08 May, 2020 2 commits
  12. 07 May, 2020 1 commit
  13. 05 May, 2020 1 commit
  14. 04 May, 2020 1 commit
  15. 24 Apr, 2020 1 commit
  16. 20 Apr, 2020 3 commits
  17. 06 Apr, 2020 1 commit
  18. 20 Feb, 2020 2 commits
  19. 18 Feb, 2020 2 commits
  20. 10 Feb, 2020 1 commit
    • Michael Lippautz's avatar
      heap: Be more conservative when delaying finalization · 7a410e73
      Michael Lippautz authored
      When delaying finalization we considered the maximum of the current time
      to task and the recorded average. In case there's no recorded average
      the GC would consider the current time to task as estimate which is too
      aggresive as V8 may never get a task executed.
      
      Be fully conservative about recorded task times and bail out in such
      cases.
      
      Bug: chromium:1049957
      Change-Id: Ibaac242f72459341a170af80e63fb2266f91b0eb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043809
      Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66196}
      7a410e73
  21. 06 Feb, 2020 1 commit
  22. 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
  23. 04 Feb, 2020 3 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: Fix marking regression when not using embedder heap tracer · 5ae7258c
      Michael Lippautz authored
      When not being embedded, there's no need to try to share time with the
      embedder.
      
      Additionally, avoid too small step sizes.
      
      Bug: chromium:1044630, chromium:1048631
      Change-Id: I227bfd120b5ce1976935d27c2140263f7364eb51
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036085
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66115}
      5ae7258c
    • 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
  24. 03 Feb, 2020 1 commit
    • Michael Lippautz's avatar
      heap: Improved incremental scheduling for unified heap · bd02f663
      Michael Lippautz authored
      When the embedder integrates in V8's garbage collector the performance
      of the atomic phase is sensitive to how much embedder memory is found
      through marking the overall transitive closure.
      
      Before this patch, V8 would help out tracing the embedder's heap when
      making progress through tasks but not on allocations. In addition, V8
      would complete the garbage collection when it has observed it's own
      marking worklists as empty 3 times (*). This can create performance
      cliffs when there's a lot of work still to be done on the embedder
      side.
      
      This patch adds helping steps on allocation that are proportional to
      the bytes that V8 would otherwise process, guaranteeing some progress
      as long as there's V8 allocations. This allows us to remove (*).
      
      Potential Tradeoffs:
      - More time spent in V8's garbage collection metrics as we slightly
        limit the chances for the embedder to mark objects through tasks.
      - Prolonged V8.execute time (JS execution)
      + Faster progress
      + Less memory
      + Smaller atomic pause time
      
      Change-Id: I160f063209f7e129b9c884206f833706b69dadc1
      Bug: chromium:1044630
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2025371
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66091}
      bd02f663
  25. 31 Jan, 2020 1 commit
  26. 24 Jan, 2020 1 commit
  27. 19 Jan, 2020 1 commit
    • Ulan Degenbaev's avatar
      [api] New v8::Isolate::MeasureMemory API with per-context sizes · 80242048
      Ulan Degenbaev authored
      This adds a new API function that can be customized by the embedder
      by providing a delegate that defines contexts to be measured and
      reports the results to JS.
      
      A memory measurement request is carried out as follows:
      
      1) MeasureMemory(delegate) invocation enqueues a new request in
         MemoryMeasurement::received_ and schedules a delayed GC task.
      
      2) At the start of the next GC (that is triggered either by the
         GC schedule or by the delayed task) each request in received_
         moves to processing_. Per-context marking worklists are created
         for each native context that was selected by the delegates
         (using the ShouldMeasure predicate).
      
      3) At the end of the GC the sizes of the native contexts are
         recorded for each request in processing_. The requests move
         to the done_ list and result reporting task is scheduled.
      
      4) When the result reporting task runs it invokes the
         MeasurementComplete function of each delegate in done_.
      
      
      Bug: chromium:973627
      
      Change-Id: I0254cae693c5b8fab7c85a9eca0a3a128210b6c4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1981493
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65856}
      80242048
  28. 17 Jan, 2020 1 commit
  29. 16 Jan, 2020 1 commit