Skip to content

V
V8
Switch branch/tag
  1. 08 Mar, 2021 1 commit
    • Michael Lippautz's avatar
      cppgc: Fix conservative stack handling · b6a96f27
      Michael Lippautz authored 
      When objects are recorded for conservative handling and the GC is
finalized conservatively, with a different stack, we rely on
MarkNotFullyConstructedObjects(). In this method, the objects are
initially marked, only to be forwarded to handlers that try to mark
them again.

Bug: chromium:1056170
Change-Id: I942e7b0ec88aae08e3fe06b7cb3ff4a86dc42f36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2744074
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73281}
      b6a96f27
  3. 25 Feb, 2021 1 commit
    • Omer Katz's avatar
      cppgc: Add WasConservativeGC to HeapState · 199359da
      Omer Katz authored 
      This CL adds WasConservativeGC to HeapState which reports whether the
last GC was finalized conservatively. The state is updated at the end of
marking atomic pause.

Currently the library integration in Blink ignores the stack state when
scheduling a forced GC for testing. That means that we always schedule
another GC after a forced GC.
This causes a crash in web_tests which assume no GC is happening
between forced GCs if the thread is not idle and no new allocations
happen.

Usage CL: https://crrev.com/c/2720201

Drive by: Fix stack state for MarkingVerifier in CppHeap.

Bug: chromium:1056170
Change-Id: I6ad23ed7c1a53fae96425b968bc4b3eb18ce80b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720279
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73064}
      199359da
  5. 18 Feb, 2021 2 commits
  7. 17 Feb, 2021 2 commits
    • Omer Katz's avatar
      cppgc: Implement process-global state accessors. · c174643b
      Omer Katz authored 
      Process global accessors for total physical size and used size are
needed for blink. These are implemented via an allocation observer that
atomically updates static counters.

The public api only provides getters for the counters. An internal class
is in charge of updating the counters as needed. A similar split is also
applied to IsAnyIncrementalOrConcurrentMarking().

Drive-by: ProcessHeap is merged into cppgc::internal::WriteBarrier.

Bug: chromium:1056170
Change-Id: Iaedebd1ac9d49238ce6bdd52ffa5d1ef4d28203d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695394
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72832}
      c174643b
    • 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
  9. 16 Feb, 2021 1 commit
    • Omer Katz's avatar
      cppgc: Handle non-gced traceable ephemeron values · 75131637
      Omer Katz authored 
      On-heap hash maps in blink are limited to Member types and non-traceable
types. The only exception to that is TraceWrapperV8Reference. Thus
ephemerons can have non-gced traceable values. This values should not be
pushed to the marking worklist since we expect everything in the
worklist to be marked and not in construction (but these values don't
have an object header).
Instead, when getting a non-gced value we should immediately trace it.

This is only relevant to ephemerons. Any other case would go through
Trace(const T&) that dispatches to the TraceTrait.

Blink has 1 use case of HeahHashMap from WeakMember<ScriptWrappable> to
TraceWrapperV8Reference.

Bug: chromium:1056170
Change-Id: Ia8f341d6bb1fc8fd3655b2be66b7814896549d1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696648Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72763}
      75131637
  11. 15 Feb, 2021 1 commit
  13. 09 Feb, 2021 1 commit
  15. 08 Feb, 2021 1 commit
  17. 28 Jan, 2021 1 commit
  19. 22 Jan, 2021 1 commit
    • Omer Katz's avatar
      cppgc: Add UMA support · adda4c5f
      Omer Katz authored 
      This CL introduces cppgc::HistogramRecorder api which is similar to the
v8::metrics::Recorder api and is used by cppgc to report histogram
samples to embedders. Embedders should implement the api if they want to
collect histograms and provide an instance of it on heap creation.

CppHeap uses an adaptor class that implements the HistogramRecorder api
and is used to forward the relevant info to the relevant
v8::metrics::Recorder.

The api used 3 data structures: 2 for incremental steps that need to be
reported as they come (marking and sweeping) and 1 for the end of a GC
cycle that aggregates statistics over the entire cycle.
The data structure only provide the "raw" samples (e.g. atomic mark
time, incremental mark time, etc...). The embedder is expected to
compute aggregate histogram on its own (e.g. overall marking time).

Bug: chromium:1056170
Change-Id: If63ef50a29a21594f654edb83084598980d221ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642258
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@{#72256}
      adda4c5f
  21. 30 Nov, 2020 1 commit
  23. 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
  25. 20 Nov, 2020 1 commit
    • Omer Katz's avatar
      Reland "cppgc: Use tracing scopes" · 2c66a0ef
      Omer Katz authored 
      This reverts commit 64bf4c53.

Reason for revert: fix in patchset 2

Original change's description:
> Revert "cppgc: Use tracing scopes"
>
> This reverts commit 548fe208.
>
> Reason for revert: Issues on Mac64: https://ci.chromium.org/p/v8/builders/ci/V8%20Mac64%20-%20debug/31710
>
> Original change's description:
> > cppgc: Use tracing scopes
> >
> > The scopes themselves mostly have the same coverage as current scopes in
> > blink. A few exception due to encapsulation exist and are highlighted as
> > comments on the CL.
> >
> > Bug: chromium:1056170
> > Change-Id: I48af2cfdfd53a8caa1ab5d805d377f6f13a825bc
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2540552
> > Commit-Queue: Omer Katz <omerkatz@chromium.org>
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#71285}
>
> TBR=ulan@chromium.org,mlippautz@chromium.org,omerkatz@chromium.org
>
> Change-Id: I20dce9309dcaeff6ea61bdc51df3a2f62c2a103f
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: chromium:1056170
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2550782
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71289}

TBR=ulan@chromium.org,mlippautz@chromium.org,clemensb@chromium.org,omerkatz@chromium.org

# Not skipping CQ checks because this is a reland.

Bug: chromium:1056170
Change-Id: I9c57cdb3b0d310366cdf3e6fbcd1254fdc363163
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2550666
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71305}
      2c66a0ef
  27. 19 Nov, 2020 3 commits
  29. 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
  31. 22 Oct, 2020 4 commits
  33. 19 Oct, 2020 1 commit
  35. 15 Oct, 2020 1 commit
  37. 09 Oct, 2020 2 commits
  39. 08 Oct, 2020 1 commit
  41. 06 Oct, 2020 2 commits
  43. 02 Oct, 2020 1 commit
    • Omer Katz's avatar
      cppgc: Mark in construction objects externally · cebd8b65
      Omer Katz authored 
      In construction objects don't have anything to sync with on the
allocation side since they weren't marked as fully constructed yet.
This could mean the initialization of the marking bit on the mutator
thread and setting the mark bit on a concurrent thread could race
(potentially resulting in losing the mark bit when the gc info index
overwrites it).

This CL fixes this issue by using a set of in construction objects.
In construction objects are no longer marked. Instead they are pushed
to the set and the heap object header is marked when they are popped
from the worklist. Since the set avoids duplicates, this allows us to
both avoid worklist explosion (due to pushing the same in construction
 object multiple times) and avoid the data race on the mark bit.

This CL uses an unordered_set to record objects. Synchronization uses
a lock, which could be costly but is not expected to be obtained often.

Bug: chromium:1056170
Change-Id: I366b59f476c166ff06e15b280df9e846034cc6cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2437388
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70282}
      cebd8b65
  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 1 commit
  57. 28 Aug, 2020 1 commit
    • Omer Katz's avatar
      cppgc: Port incremental marking schedule · f13c55d7
      Omer Katz authored 
      Schedule is simpler compared to the schedule in blink since it now
returns deadlines based on marked bytes instead of time.

If marking is ahead of schedule, return the minimum step size.
Otherwise, set step size to catch up to schedule (ignoring the time
passed while performing the step).
No more default initial step size (needed in blink since marking speed
was unknown).
If estimated schedule is exceeded (marking takes longer than 500ms), the
steps will try to mark all remaining objects but would still be capped
by the maximum step duration of 2ms.

Bug: chromium:1056170
Change-Id: I09857db161c621a12d064f9c8c21b646c34f9d71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375200
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarAnton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69602}
      f13c55d7