This CL introduces concurrent marking to the cppgc library.
The CL includes:
(*) Split MarkingState to mutator thread and concurrent thread.
(*) Split MarkingVisitor to mutator thread and concurrent thread.
(*) Introduce ConcurrentMarker for managing concurrent marking.
(*) Update unified heap to support concurrent marking as well.
See slides 13 and 14 in the following link for class hierarchies:
https://docs.google.com/presentation/d/1uDiEjJ-f1VziBKmYcvpw2gglP47M53bwj1L-P__l9QY/
Bug: chromium:1056170
Change-Id: I6530c2b21613011a612773d36fbf37416c23c5e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424348
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@{#70352}
To support compaction of backing stores in blink, we need to distinguish
custom spaces holding backing stores from other custom spaces.
Custom space compactablity is explicitly declared as an enum value and
propagated to BaseSpace as a bool flag.
Note that even if/when general compaction is implemented/enabled for
normal pages we will still need such a marking for supporting
non-compactable custom spaces.
Bug: v8:10990
Change-Id: I165a0268ded121e91399834a4091e88e57f2565c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2449973
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70345}
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: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70282}
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: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70259}
This reverts commit 2221f0909b.
Reason for revert: fix in patchset 2
Original change's description:
> Revert "cppgc: Provide jobs support through DefaultPlatform and TestPlatform"
>
> This reverts commit 22c0fc8f2e.
>
> Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20gcc/8712?
>
> Original change's description:
> > cppgc: Provide jobs support through DefaultPlatform and TestPlatform
> >
> > This CL extends cppgc::DefaultPlatform and TestPlatform to emulate
> > jobs using std::thread and v8::base::Thread respectively.
> > Jobs using these platform do not yield unless the job as been
> > cancelled. Additionally, the job priority is ignored.
> >
> > Bug: chromium:1056170
> > Change-Id: I72db1eef410d2be3d3e5ea7d4ece9e5584a451f2
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416378
> > 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@{#70139}
>
> TBR=mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org
>
> Change-Id: Ic29235e3ab78a1b515a5b14b808e116a1ccffc0f
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: chromium:1056170
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2432087
> Reviewed-by: Francis McCabe <fgm@chromium.org>
> Commit-Queue: Francis McCabe <fgm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70142}
# Not skipping CQ checks because this is a reland.
Bug: chromium:1056170
Change-Id: Iaa8312da759ab97f646a9fb6144462a115393b5f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431666
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70150}
This reverts commit 22c0fc8f2e.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20gcc/8712?
Original change's description:
> cppgc: Provide jobs support through DefaultPlatform and TestPlatform
>
> This CL extends cppgc::DefaultPlatform and TestPlatform to emulate
> jobs using std::thread and v8::base::Thread respectively.
> Jobs using these platform do not yield unless the job as been
> cancelled. Additionally, the job priority is ignored.
>
> Bug: chromium:1056170
> Change-Id: I72db1eef410d2be3d3e5ea7d4ece9e5584a451f2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416378
> 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@{#70139}
TBR=mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org
Change-Id: Ic29235e3ab78a1b515a5b14b808e116a1ccffc0f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2432087
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70142}
This CL extends cppgc::DefaultPlatform and TestPlatform to emulate
jobs using std::thread and v8::base::Thread respectively.
Jobs using these platform do not yield unless the job as been
cancelled. Additionally, the job priority is ignored.
Bug: chromium:1056170
Change-Id: I72db1eef410d2be3d3e5ea7d4ece9e5584a451f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416378
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@{#70139}
To let the user do special handling on the main thread e.g. Scavenging
uses different tracing categories for background/foreground threads.
Change-Id: I6c9187fd6201b5b81cd83727727fda49fcf7ff68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2405797
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69978}
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: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69971}
This CL migrates cppgc to use Ulan's new worklist implementation.
Since there is no central segments array anymore, we cannot rely on
getting the same view (now renamed to Local) given the same task id.
To avoid creating many short lived segments (e.g. for write barriers)
marking state now holds local views for all worklists and provides
access to them.
Bug: chromium:1056170
Change-Id: Id19fe1196b79ed251810e91074046998dc2a9177
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390771
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69767}
The handle was always created empty which resulted in a DCHECK crash
in debug builds and in never-cancelled tasks in release builds.
Bug: chromium:1056170
Change-Id: I798ce65c37738bbe9c60b44b692ff04536f6d830
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2388101
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69653}
Heap growing estimates when to start incremental gc such that it
will finish when we are expecting to finalize (i.e. when an atomic
gc would be triggered).
There is also a minimum ratio between limit for atomic gc and limit
for incremental gc, to guarantee that incremental gc get's some time to
run even with the application rarely allocates.
This is a continuation of:
https://chromium-review.googlesource.com/c/v8/v8/+/2377691
Bug: chromium:1056170
Change-Id: I8c87e98d60b6f8b5748558771a236f15385f7858
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381454
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69630}
Explicit nullification aims to simplify migration to Oilpan, in the
case when unique_ptrs are converted to Member and user code relies on
source pointers to be in "empty" state.
Change-Id: Ia54137d53ca03f93932b3c1f2eaba439a416a06e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379857
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69603}
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: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69602}
Starting marking required Creating a Marker and calling StartMarking.
StartMarking should always have been called immediately after creating
the marker.
Since markers are not persisted between GC (a marker exists only while
marking is in progress), it makes sense to start marking implicitly when
a marker is created.
Calling StartMarking in MarkerBase ctor is inadvisable since subclasses
might still to initialize fields.
Using MarkerFactory instead guarantees that StartMarking is always
called immediately after creating a Marker.
Bug: chromium:1056170
Change-Id: Icbf11afd848e1618c204ca6bf951600b3ae9fef2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375199
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69601}
- JobHandle::IsCompleted()
- JobDelegate::GetTaskId()
- worker_count passed as argument to GetMaxConcurrency().
Jobs implementation must call the new GetMaxConcurrency(), but Jobs
users aren't migrated yet.
Bug: chromium:1114823
Change-Id: I0f4295ccaf9eba866dd771f30e2e49aa3eae9551
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352484
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69553}
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/+/2299374
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69506}
This CL adds a basic implementation of incremental marking for standalone GC.
Followup CLs include:
* Use bytes instead of time as deadline
* Port incremental marking schedule from blink
* Mark on allocation
* Guarantees for progres/termination for standalone GC
* etc...
Calling StartIncrementalGarbageCollection triggers StartMarking which
schedules incremental marking as non-nestable tasks.
For unified heap, marking will continue running until it runs out of
work but it won't finalize independently.
For standalone, when incremental runs out of work it will schedule a new
task in which it will finalize marking and trigger the rest of the GC.
Users of standalone can also force finalization before incremental
marking as finished using FinalizeIncrementalGarbageCollectionIfRunning.
Calling CollectGarbage would also finalize an on-going incremental GC
if one exists. Otherwise it will trigger an atomic GC.
See the following doc for explanation of the various methods:
https://docs.google.com/document/d/1ZhJY2fOoD8sH53ZxMh2927Zl8sXqA7azJgcQTWx-YKs/edit?usp=sharing
Bug: chromium:1056170
Change-Id: I75ead414eb9da9f8b7f71c4638b9830fce7708ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2298009
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69480}
This is a revival of https://chromium-review.googlesource.com/c/v8/v8/+/2228332
The CL establishes the following:
*) Objects are marked before being pushed to the worklists.
*) Live bytes are always accounted after tracing an object (i.e. move
from Gray to Black below).
*) Previously not fully constructed objects are traced immediately
instead of pushed to the marking worklist.
This establishes the following invariants for all marking worklists:
1) White = !object.is_marked() && !worklist.contains(object)
2) Gray = object.is_marked() && worklist.contains(object)
3) Black = object.is_marked() && !worklist.contains(object)
Bug: chromium:1056170
Change-Id: I821573b3fbc057e6ffb836154271ff986ecb4d2b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336797
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69268}
This CL ports MarkingVerifier from blink.
The existing verifier checks only references on heap.
This new verifier checks references both on heap and on stack.
Bug: chromium:1056170
Change-Id: I083dcb0087125312cca34a2201015a9aecfe6ea4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2300484
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68891}
This CL removes the GetTraceDescriptor virtual call from garbage
collected mixins and replaces it with querying the object start
bitmap.
The CL also removes the mixin macros which are now no longer needed.
Bug: chromium:1056170
Change-Id: I27ed299f93025d09a3bb3f0d17b14bed3c200565
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2287508
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68787}
Split off MarkingWorklists and from Marker and introduce MarkerBase.
MarkerBase refers just to interfaces types for passing along visitors.
The concrete Marker provides the impl for these interfaces. Unified
heap marker uses different marking visitors internally but provides an
implementation for the same interface.
Change-Id: Ibc4b2c88e2e69bd303a95da7d167a701934f4a07
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2270539
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68676}
Split off MarkingState from MarkingVisitor.
With this CL the marking implementation is moved to "MarkingState"
which is the new bottleneck for marking a single object.
MarkingVisitor merely forwards to MarkingState, which knows how to set
the markbit and add the object to the worklist accordingly. This
allows to have a "UnifiedHeapMarkingVisitor" in future which can
easily reuse Marking to provide C++ marking.
Change-Id: I87ebbe37e8e8cd841e872cae9dc3490e2b55c4dd
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2270172
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68660}
This allows the implementation of different stack scanning mechanisms in
V8 (e.g. conservative scanning) while re-using the stack walking API.
Change-Id: I9b9c3b8ffe5d527ca3f7105776821776b509b187
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238194
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68457}
This is a reland of e0c1a349ea
The issue was passing SentinelPointer (== +1) through T*.
The fix is disabling cfi unrelated cast diagnostic for the bottlenecks
(Get()). This means that nullptr is treated the same as
kSentinelPointer.
The alternative would be a DCHECK that Get() does not return
kSentinelPointer and adjusting all Member and Persistent logic that
uses Get() to work on void*. This is quite intrusive as it involves
Swap(), heterogeneous assignments, comparisons, etc.
Original change's description:
> cppgc: Properly clear (Weak)Peristent and WeakMember pointers
>
> The CL addresses two issues with (Weak)Persistent and WeakMember:
> 1. (Weak)Persistent pointers are cleared on heap teardown. Before this
> CL the pointers would contain stale values which could lead to UAF.
> 2. WeakPersistent and WeakMember are cleared using a combination of
> internal clearing methods and mutable fields which avoids the use
> of const_cast<>.
>
> Bug: chromium:1056170
> Change-Id: Ibf2b0f0856771b4f6906608cde13a6d43ebf81f3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2248190
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68394}
Bug: chromium:1056170
Change-Id: I3d74b43464c2973df1956f51b1419d755dd9f519
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250240
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68426}
The CL addresses two issues with (Weak)Persistent and WeakMember:
1. (Weak)Persistent pointers are cleared on heap teardown. Before this
CL the pointers would contain stale values which could lead to UAF.
2. WeakPersistent and WeakMember are cleared using a combination of
internal clearing methods and mutable fields which avoids the use
of const_cast<>.
Bug: chromium:1056170
Change-Id: Ibf2b0f0856771b4f6906608cde13a6d43ebf81f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2248190
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68394}
This adds the following things:
- age table for 4K regions;
- generational barrier for mixed 4K regions;
- unmarking for major collections;
- young generation flags.
Bug: chromium:1029379
Change-Id: Ief1229f0dac5f90c5f06d3168c8ffb4b7d1f1b53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2246566
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68379}
Since the registration requires calling into the library, there's no
reason to get the heap through a magic getter on API level.
Bug: chromium:1056170
Change-Id: I8d2b1d0fcee8c855908bd26c71a22826c493ed29
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238568
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68315}
Unified heap support in V8 requires having another (at least internal)
heap that implements a unfied garbage collection strategy. This will
not re-use the already existing cppgc::Heap because there should be no
way in creating such a heap externally or scheduling stand-alone
garbage collections.
In order to have a common token, this CL introduces AllocationHandle
which can be passed to MakeGarbageCollected to allocate C++ objects.
V8 (soon) and the stand-alone heap both have methods to retrieve such
a handle.
This works around a problem with creating diamond class hierarchies
when a base class would be exposed on the public API level.
Fast paths for Blink are still possible because allocation handles can
be cached the same way (e.g. global, or TLS) as a heap can be cached.
Tbr: yangguo@chromium.org
Bug: chromium:1056170
Change-Id: I8e9472a2c24ef82d1178953e8429b1fd8a2344bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238027
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68310}
This fixes two issues:
- labs resetting didn't account bytes as beeing freed;
- large object were not accounted.
The CL introduces a single bottleneck for labs resetting in
ObjectAllocator, which is aware of StatsCollector. This way
NormalSpace is treated as a value object and all invariants
are maintained by ObjectAllocator (and Sweeper).
Bug: chromium:1056170
Change-Id: I027cc01fe5028a3dfa81905d7ea53dd12d1c1f20
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2237629
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68286}
Adds allocation-based heap growing strategy that triggers GC based on
some limit. The limit is computed based on previous live memory and a
constant growing factor.
For invoking GC, we support two modes: with and without conservative
stack scanning. Without conservative stack scanning, an invoker makes
sure that we schedule a GC without stack using the existing platform.
Bug: chromium:1056170
Change-Id: I1808aeb5806a6ddd5501b556d6b6b129a85b9cda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228887
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68235}
The observers can use ResetAllocatedObjectSize() to e.g. implement a
growing strategy that resets its limit on this call.
Bug: chromium:1056170
Change-Id: Ib9553e00cc530ff89f44e4258c13d47f0b70568e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228885
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68205}
This ports HeapStatsCollector (former ThreadHeapStatsCollector) from
Blink. The CL only ports accounting of allocated object size which is
needed for a simple growing strategy in a follow up.
HeapStatsCollector is a global dependency for most sub components as
it provides infrastructure for measuring time (through trace scopes)
and space.
The general idea of HeapStatsCollector is to act as sink where all sub
components push time and space information. This information is then
gathered and made available via an event that is implemented as POD.
Time-dependent info is available through regular getters (pull) and
observers (push).
Change-Id: I40b4d76e1a40c56e5df1a7353622318cde730e26
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2225902
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68150}
