Skip to content

V
V8
Switch branch/tag
  1. 12 May, 2022 1 commit
    • Michael Lippautz's avatar
      Reland "[heap] Refactor atomic marking phase" · bd9ed6ce
      Michael Lippautz authored 
      This is a reland of commit 25e32252

Original change's description:
> Reland "[heap] Refactor atomic marking phase"
>
> This is a reland of commit a3f66927
>
> The reland addresses a few CHECKs that were too agressive and also
> properly adjusts Oilpan's marking configurations depending on V8's
> flags.
>
> Original change's description:
> > [heap] Refactor atomic marking phase
> >
> > The atomic marking phase was organized in many distinct smaller
> > phases. In particular, before http://crrev.com/c/3584115 the marking
> > phase split into two large separate phases.
> >
> > This CL reorganizes marking into two phases that perform regular V8
> > heap marking, Oilpan, and ephemerons:
> > - A parallel phase that likely drains all marking worklists;
> > - A single-threaded final phase to catch any left overs;
> >
> > This avoids artificial splitting in phases and also avoids repeated
> > starting and joining of jobs.
> >
> > Change-Id: I5cccfc5777837d9ece10d8f4925781bf2d07d9da
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3602507
> > Reviewed-by: Omer Katz <omerkatz@chromium.org>
> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#80265}
>
> Change-Id: I26648da361b92d787c173aa9d390100ce8958728
> Bug: chromium:1320896
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616519
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80301}

Bug: chromium:1320896
Change-Id: I7ebb3bde9f0d3497f46c728bfbc380c1bd4bc021
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3641167Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80485}
      bd9ed6ce
  3. 02 May, 2022 2 commits
    • Leszek Swirski's avatar
      Revert "Reland "[heap] Refactor atomic marking phase"" · 3d3d9c50
      Leszek Swirski authored 
      This reverts commit 25e32252.

Reason for revert: Suspect for roll failure: https://ci.chromium.org/ui/p/chromium/builders/try/android_optional_gpu_tests_rel/98554/overview

Original change's description:
> Reland "[heap] Refactor atomic marking phase"
>
> This is a reland of commit a3f66927
>
> The reland addresses a few CHECKs that were too agressive and also
> properly adjusts Oilpan's marking configurations depending on V8's
> flags.
>
> Original change's description:
> > [heap] Refactor atomic marking phase
> >
> > The atomic marking phase was organized in many distinct smaller
> > phases. In particular, before http://crrev.com/c/3584115 the marking
> > phase split into two large separate phases.
> >
> > This CL reorganizes marking into two phases that perform regular V8
> > heap marking, Oilpan, and ephemerons:
> > - A parallel phase that likely drains all marking worklists;
> > - A single-threaded final phase to catch any left overs;
> >
> > This avoids artificial splitting in phases and also avoids repeated
> > starting and joining of jobs.
> >
> > Change-Id: I5cccfc5777837d9ece10d8f4925781bf2d07d9da
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3602507
> > Reviewed-by: Omer Katz <omerkatz@chromium.org>
> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#80265}
>
> Change-Id: I26648da361b92d787c173aa9d390100ce8958728
> Bug: chromium:1320896
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616519
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80301}

Bug: chromium:1320896
Change-Id: I01742f25d54de8e4e22fefe87ce61ba295950baa
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3620286
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80311}
      3d3d9c50
    • Michael Lippautz's avatar
      Reland "[heap] Refactor atomic marking phase" · 25e32252
      Michael Lippautz authored 
      This is a reland of commit a3f66927

The reland addresses a few CHECKs that were too agressive and also
properly adjusts Oilpan's marking configurations depending on V8's
flags.

Original change's description:
> [heap] Refactor atomic marking phase
>
> The atomic marking phase was organized in many distinct smaller
> phases. In particular, before http://crrev.com/c/3584115 the marking
> phase split into two large separate phases.
>
> This CL reorganizes marking into two phases that perform regular V8
> heap marking, Oilpan, and ephemerons:
> - A parallel phase that likely drains all marking worklists;
> - A single-threaded final phase to catch any left overs;
>
> This avoids artificial splitting in phases and also avoids repeated
> starting and joining of jobs.
>
> Change-Id: I5cccfc5777837d9ece10d8f4925781bf2d07d9da
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3602507
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80265}

Change-Id: I26648da361b92d787c173aa9d390100ce8958728
Bug: chromium:1320896
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616519
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80301}
      25e32252
  5. 28 Apr, 2022 2 commits
    • Adam Klein's avatar
      Revert "[heap] Refactor atomic marking phase" · 349d4513
      Adam Klein authored 
      This reverts commit a3f66927.

Reason for revert: test failures on TSAN/no-concurrent-marking bot:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20no-concurrent-marking/8549/overview

Original change's description:
> [heap] Refactor atomic marking phase
>
> The atomic marking phase was organized in many distinct smaller
> phases. In particular, before http://crrev.com/c/3584115 the marking
> phase split into two large separate phases.
>
> This CL reorganizes marking into two phases that perform regular V8
> heap marking, Oilpan, and ephemerons:
> - A parallel phase that likely drains all marking worklists;
> - A single-threaded final phase to catch any left overs;
>
> This avoids artificial splitting in phases and also avoids repeated
> starting and joining of jobs.
>
> Change-Id: I5cccfc5777837d9ece10d8f4925781bf2d07d9da
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3602507
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80265}

Change-Id: I4838e9316bd30f8a0b78fa6a27820d3457e1e579
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3614972
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80267}
      349d4513
    • Michael Lippautz's avatar
      [heap] Refactor atomic marking phase · a3f66927
      Michael Lippautz authored 
      The atomic marking phase was organized in many distinct smaller
phases. In particular, before http://crrev.com/c/3584115 the marking
phase split into two large separate phases.

This CL reorganizes marking into two phases that perform regular V8
heap marking, Oilpan, and ephemerons:
- A parallel phase that likely drains all marking worklists;
- A single-threaded final phase to catch any left overs;

This avoids artificial splitting in phases and also avoids repeated
starting and joining of jobs.

Change-Id: I5cccfc5777837d9ece10d8f4925781bf2d07d9da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3602507Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80265}
      a3f66927
  7. 11 Apr, 2022 2 commits
    • Michael Lippautz's avatar
      Reland "cppgc-js: Concurrently process v8::TracedReference" · 2da23bd5
      Michael Lippautz authored 
      This is a reland of commit 1f0d7d20

The fix merges concurrent marking tasks when marking in the atomic
pause. Without the fix, Oilpan markers would continue running
concurrently, possibly discovering new V8 objects. This violates the
assumption that the final transitive closure runs on a single thread.

Original change's description:
> cppgc-js: Concurrently process v8::TracedReference
>
> Adds concurrent marking for reaching through v8::TracedReference.
> Before this CL, a v8::TracedReference would always be processed on the
> main thread by pushing a callback for each encountered reference.
>
> This CL now wires up concurrent handling for such references. In particular:
> - Global handles are already marked as well and not repurposed during
>   the same GC cycle.
> - Since global handles are not repurposed, it is enough to
>   double-deref to the V8 object, checking for possible null pointers.
> - The bitmap for global handle flags is mostly non-atomic, with the
>   markbit being the exception.
> - Finally, all state is wired up in CppHeap. Concurrent markers keep
>   their own local worklist while the mutator marker directly pushes to
>   the worklist owned by V8.
>
> Bug: v8:12600
> Change-Id: Ia67dbd18a57dbcccf4dfb9ccfdb9ee438d27fe71
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516255
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79736}

Bug: v8:12600
Change-Id: I8545041b2c7b3daf7ecea7e3a100e27534e9b8b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571887Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79919}
      2da23bd5
    • Michael Lippautz's avatar
      cppgc: Join concurrent marking instead of cancelling · 25a55381
      Michael Lippautz authored 
      Join instead of cancel to make use of the the main thread.

Also make the Join() call explicit instead of implicitly finishing
concurrency on advancing tracing form the main thread.

Bug: v8:12600
Change-Id: I60d3e82bfc2e8a3ccc2dda761a5d3eb3ac7694d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3578855Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79910}
      25a55381
  9. 08 Apr, 2022 2 commits
  11. 05 Apr, 2022 1 commit
    • Leszek Swirski's avatar
      Revert "cppgc-js: Concurrently process v8::TracedReference" · 64e89350
      Leszek Swirski authored 
      This reverts commit 1f0d7d20.

Reason for revert: Speculative revert for roll failures in https://chromium-review.googlesource.com/c/chromium/src/+/3569445

Original change's description:
> cppgc-js: Concurrently process v8::TracedReference
>
> Adds concurrent marking for reaching through v8::TracedReference.
> Before this CL, a v8::TracedReference would always be processed on the
> main thread by pushing a callback for each encountered reference.
>
> This CL now wires up concurrent handling for such references. In particular:
> - Global handles are already marked as well and not repurposed during
>   the same GC cycle.
> - Since global handles are not repurposed, it is enough to
>   double-deref to the V8 object, checking for possible null pointers.
> - The bitmap for global handle flags is mostly non-atomic, with the
>   markbit being the exception.
> - Finally, all state is wired up in CppHeap. Concurrent markers keep
>   their own local worklist while the mutator marker directly pushes to
>   the worklist owned by V8.
>
> Bug: v8:12600
> Change-Id: Ia67dbd18a57dbcccf4dfb9ccfdb9ee438d27fe71
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516255
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79736}

Bug: v8:12600
Change-Id: I8a91dcd6880580207bf8d315b264edbe42a794e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568474
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79778}
      64e89350
  13. 04 Apr, 2022 1 commit
    • Michael Lippautz's avatar
      cppgc-js: Concurrently process v8::TracedReference · 1f0d7d20
      Michael Lippautz authored 
      Adds concurrent marking for reaching through v8::TracedReference.
Before this CL, a v8::TracedReference would always be processed on the
main thread by pushing a callback for each encountered reference.

This CL now wires up concurrent handling for such references. In particular:
- Global handles are already marked as well and not repurposed during
  the same GC cycle.
- Since global handles are not repurposed, it is enough to
  double-deref to the V8 object, checking for possible null pointers.
- The bitmap for global handle flags is mostly non-atomic, with the
  markbit being the exception.
- Finally, all state is wired up in CppHeap. Concurrent markers keep
  their own local worklist while the mutator marker directly pushes to
  the worklist owned by V8.

Bug: v8:12600
Change-Id: Ia67dbd18a57dbcccf4dfb9ccfdb9ee438d27fe71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516255Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79736}
      1f0d7d20
  15. 27 Dec, 2021 1 commit
    • Omer Katz's avatar
      cppgc-js, heap: Concurrently push references from v8 to Oilpan · d10f61e1
      Omer Katz authored 
      Included in this CL:
(*) Introduce CppMarkingState that V8 should use to push references to
    Oilpan. CppMarkingState allocates its own Worklist::Locals to
    support concurrent updates from V8.
(*) Split Oilpan MarkingWorklist object to form a base class used by
    CppMarkingState.
(*) Remove MarkerFactory and split marking initialization. Marking
    worklists should already be initialized when V8 initializes
    visitors. For incremental marking, this requires splitting
    marking initialization and marking start.
(*) Drive-by: Mark JSObject::IsApiWrapper and
    JSObject::IsDroppableApiWrapper as const.

Bug: v8:12407
Change-Id: I35cc816343da86f69a68306204675720e9b3913f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293410Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78446}
      d10f61e1
  17. 09 Dec, 2021 1 commit
  19. 25 Nov, 2021 3 commits
  21. 07 Oct, 2021 1 commit
  23. 29 Sep, 2021 1 commit
    • Michael Lippautz's avatar
      cppgc: Delay CrossThreadPersistent processing · e57ec7ae
      Michael Lippautz authored 
      During a final atomic pause CrossThreadPersistent handles need to be
frozen after they have been marked to avoid any
WeakCrossThreadPersistent handles creating new strong references
(through their Lock() call) that would retain objects.

Handles are frozen by acquiring a lock. Since this lock is also taking
by other threads on WCTP::Lock() this can introduce jank.

This CL improves the situation by delaying processing of CTP
references until absolutely necessary, i.e., when we have otherwise no
more objects to mark.

Bug: chromium:1252743
Change-Id: I872f38c6d24d7955bea74fd59685abd3019b385e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3194253Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77139}
      e57ec7ae
  25. 19 May, 2021 1 commit
  27. 17 Feb, 2021 1 commit
    • Omer Katz's avatar
      cppgc: Fix IsMarking checks. · 81078e2b
      Omer Katz authored 
      IsMarking returns true as long as a marker exists. That means IsMarking
is true during weak processing as well.
ActiveScriptWrappableManager in blink uses a weak callback that updates
a HeapVector and thus can trigger a write barrier during the atomic
pause (which violates a DCHECK in the barrier).

Bug: chromium:1056170
Change-Id: I6304b38da9751320836a5e2407e8c7d529367bad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2700676Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72831}
      81078e2b
  29. 09 Feb, 2021 1 commit
  31. 10 Dec, 2020 1 commit
  33. 24 Nov, 2020 1 commit
    • Michael Lippautz's avatar
      cppgc: Expose write barriers · 3b82f4c6
      Michael Lippautz authored 
      Exposes an opaque handle for uniformly (cppgc and V8) referring to an
instance of a heap.

Exposes a set of raw write barriers for advances embedders through
subtle::HeapConsistency which is a mirror into write barrier internals.
The following barriers are exposed:
- DijkstraWriteBarrier: Regular Dijkstra-style write barrier (add to
  wavefront);
- DijkstraWriteBarrierRange: Same as DijkstraWriteBarrier but
  operating on a range of slots that are composite (inlined) objects;
- SteeleWriteBarrier: Regular Steele-style write barrier (retreating
  wavefront);

Change-Id: Ib5ac280204686bf887690f72df1cdb506ea6ef70
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2554601Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Reviewed-by: 's avatarAnton Bikineev <bikineev@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71381}
      3b82f4c6
  35. 19 Nov, 2020 1 commit
    • Omer Katz's avatar
      cppgc: Add tracing scopes · 6a1a3a10
      Omer Katz authored 
      This CL adds tracing scopes for the various cppgc classes.
Scopes use TRACE_EVENT_BEGIN and TRACE_EVENT_END macros to report trace
events. To do so they need to include trace-event.h. For unified heap
builds, trace-event.h forwards to v8's src/tracing/trace-event.h. For
other builds, trace-event.h provides a subset of
src/tracing/trace-event.h that covers just the parts used by cppgc.

This CL covers what we need for traces and blink gc metrics (up to
renaming events from BlinkGC.* to CppGC.*). UMA and UKM are not yet
handled.

Bug: chromium:1056170
Change-Id: Id92e84b27259ff0aadae7692f3d79d30896fb8e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2540548
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71284}
      6a1a3a10
  37. 23 Oct, 2020 1 commit
    • Omer Katz's avatar
      Reland "cppgc: Port backing store compaction." · b5979eaa
      Omer Katz authored 
      This is a reland of 90ea9b35

Original change's description:
> cppgc: Port backing store compaction.
>
> This CL ports the existing backing store compaction algorithm from
> blink. It does not attempt to improve on the existing algorithm.
>
> Currently only unified heap uses the compaction implementation. It is
> never triggered through standalone GCs.
>
> The compaction implementation resides within an internal "subtle" namespace.
>
> Bug: v8:10990
> Change-Id: I4aa781db1b711e7aafc34234c4fb142de84394d7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485228
> Commit-Queue: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70714}

Bug: v8:10990
Change-Id: I527c2042a26648d058bfe4d355527cce9a3eeadc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2492331
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70736}
      b5979eaa
  39. 22 Oct, 2020 4 commits
  41. 09 Oct, 2020 1 commit
  43. 06 Oct, 2020 1 commit
  45. 01 Oct, 2020 1 commit
    • Michael Lippautz's avatar
      cppgc: Move ProcessWeakness into FinishMarking · 20e1ba28
      Michael Lippautz authored 
      For cross-thread handling we require the atomic marking pause to
provide an atomically consistent view of markbits and weak references.
This is ensured by locking the whole atomic pause from entering to
weak processing.

This CL move ProcessWeakness() into FinishMarking() which allows to
nicely scope the upcomming lock from EnterAtomicPause() to
LeaveAtomicPause(). The alternative is requiring the caller to ensure
proper locking which is harder than ensuring that the Marker is
consistent.

Bug: chromium:1056170
Change-Id: Ib6028a0d76fcf9422c4a0d422fec3d568f106bf2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442620
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70259}
      20e1ba28
  47. 28 Sep, 2020 2 commits
  49. 25 Sep, 2020 2 commits
  51. 23 Sep, 2020 1 commit
  53. 17 Sep, 2020 1 commit
    • Omer Katz's avatar
      cppgc: Support incremental marking without non-nested tasks · 58ca454f
      Omer Katz authored 
      For the standalone library, some platform implementations might not
support non-nested tasks. We can still offer incremental marking in
such cases using regular tasks and without assuming an empty stack.
(cppgc's default platform e.g. doesn't support non-nested tasks.)

This CL also updates GCInvoker to not trigger an incremental GC if we
won't be able to finalize it. That makes finalizing through an
non-nested incremental task safe.

Bug: chromium:1056170
Change-Id: I85f0c9f2efe643cb87dd65d80417eea0d6ee5d52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414217
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69971}
      58ca454f
  55. 09 Sep, 2020 2 commits