3f5c2dda67
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} |
||
|---|---|---|
| .. | ||
| api-constants.h | ||
| atomic-entry-flag.h | ||
| caged-heap-local-data.h | ||
| compiler-specific.h | ||
| finalizer-trait.h | ||
| gc-info.h | ||
| logging.h | ||
| name-trait.h | ||
| persistent-node.h | ||
| pointer-policies.h | ||
| prefinalizer-handler.h | ||
| write-barrier.h | ||