Thread through compressed pointer into write barrier to allow to delay
compression after checking whether a write barrier is actually needed.
Change-Id: If7e6cbb69a57cc9aeeb551c11f685bace4e56c4c
Bug: chromium:1325007
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769826
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81816}
Currently, young generation assumes that all the on-heap pointers are
compressed, which is currently not the case due to the backing-store
pointers in Blink. Fixing collections to have Member<> is not easy,
because the inlined collections may have the semantics that
backing_pointer_ == inlined_buffer_;
where the inlined_buffer_ can be off-heap (e.g. on stack).
The CL introduces another type of barrier specifically for uncompressed
pointers. The followup is to use that barrier from Blink.
Bug: chromium:1029379
Change-Id: If0f519220658268dbdf915235c2e5afd7887dc0c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695358
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81105}
The generational barrier for source objects records the entire source
object to be processed later during remembered set visitation. It's
planned to be used for Blink backing stores when an inlined object (or a
range thereof) is added (HeapAllocator::NotifyNewObject(s)).
An alternative approach would be to eagerly process the inlined objects
using a custom callback. However, this requires changing Visitors to
bring slots into the context. This approach should better work for
scenarios where small ranges or single elements are added, to avoid
processing potentially large backing stores. The followup CL implements
this idea.
Bug: chromium:1029379
Change-Id: Iacb59e4b10a66354526ed293d7f43f14d8761a8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3460402
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79073}
GetWriteBarrierType used to consider the slot so that a barrier is not
triggered for on-stack slots. For strongifying weak collections we want
the write barrier to trigger even if the backing store is only reachable
from stack.
Blink counterpart: crrev.com/c/3162170
Bug: chromium:1244057
Change-Id: I75b1ca62ad5de7bae3d2f4c1a9acce839f3ccdc1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162127
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76872}
Some types of supported low-level write barrier only requires passing
a slot, which may not be even part of a heap object but stack.
This complicates the situation, as even with caged heap, there's no
way to distinguish a stack and heap slot.
Solve this by passing an optional callback that can lazy be used to
get the heap. This can be used by the embedder to retrieve the heap
from e.g. TLS if needed. This aligns the barrier with Oilpan in
Blink.
Bug: chromium:1056170
Change-Id: I1e5d022ab17a2614a67b6ef39ed12691bcbd0ac6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2675924
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72550}
Adds getters for GC phases to be used by advanced embedders to ensure
and check consistency conditions as needed.
Bug: chromium:1056170
Change-Id: Ia0b219f838bf31f0edbfe40585b95bb5eafa734d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2658328
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72430}
Allows for prohibiting GCs and will result in a crash in case a GC
finalization event is triggered.
Complements NoGarbageCollectionScope which ignores GC finalization
events.
Bug: chromium:1056170
Change-Id: Ie2a72a8675462b24692225af17c8f284318337ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2656260
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72413}
The API allows for querying
- IsAllocationAllowed: Certain GC phases prohibit allocation which can
be queried; Should be mostly used for debugging checks.
- IsMarking: Allows for querying whether the garbage collector is
currently marking.
Bug: chromium:1056170
Change-Id: I20ba5fb5be9de6694e8418fa885920eb04bd75ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649257
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72359}
Refactor write barriers and split calls, as e.g. DijkstraWriteBarrier
also contained logic for recording slots (cards) for the young
generation.
The new API exposes the following:
- GetWriteBarrierType(): Retrieving the type of barrier that must be
emitted;
- DijkstraWriteBarrier(), DijkstraWriteBarrierRange(): Dijkstra-style
write barriers;
- SteeleWriteBarrier(): Steele-style write barrier;
- GenerationalBarrier(): Barrier for recording slots when using
multiple generations;
Compilers running with -O3 optimize the DijkstraWriteBarrierPolicy
down to the same instructions as before the split.
Change-Id: If68839cc6357b2f568986c9ce8ca753b1e96a70a
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557514
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@{#71407}
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/+/2554601
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@{#71381}
