Gc on Opensource internals

Scavenging the Young Generation: How V8 Copies Live Objects in Milliseconds

Jay Hubbert — Wed, 21 Oct 2026 18:50:00 +0000

TL;DR: V8’s young generation is two semi-spaces. A scavenge copies every live object from the from-space into the to-space with Cheney’s copying algorithm, then swaps them. The copy is what makes the collection cheap: no marking, no free lists - dead objects are simply not copied. The trick that makes it parallel-safe is a relaxed compare-and-swap on the object’s map word: whoever wins the CAS owns the copy, and the losers read the winner’s forwarding address out of the same word.

JavaScript allocates like a program that never frees anything, and the heap grows and shrinks as objects die. V8 does not want to run a general-purpose collector every few milliseconds - the pause would swamp the program.

So V8 splits the problem in two. Freshly allocated objects are cheap to reclaim: if almost nothing is going to survive, the fastest way to find the garbage is not to find it at all, but to copy the survivors out of the way and let the rest evaporate. That is the scavenger, and it is why a young collection in V8 is measured in single-digit milliseconds.

Two semi-spaces and a swap

 cpp
 
 
// src/heap/new-spaces.h:35
enum SemiSpaceId { kFromSpace = 0, kToSpace = 1 };

// -----------------------------------------------------------------------------
// SemiSpace in young generation
//
// A SemiSpace is a contiguous chunk of memory holding page-like memory chunks.
// The mark-compact collector uses the memory of the first page in the from
// space as a marking stack when tracing live objects.

The mutator allocates into the to-space. When the scavenge starts, the two are swapped, and the to-space becomes the from-space:

 cpp
 
 
// src/heap/new-spaces.cc:668
void SemiSpaceNewSpace::SwapSemiSpaces() {
 // Flip the semispaces. After flipping, to space is empty and from space has
 // live objects.
 SemiSpace::Swap(&from_space_, &to_space_);
 to_space_.Reset();
 from_space_.Reset();
 quarantined_size_ = 0;
 allocation_top_ = kNullAddress;
 DCHECK_EQ(0u, Size());

Swapping two pointers is the whole “flip”. There is no per-object work, no free list to walk, no mark bits to clear. After the swap the to-space is empty and ready for the mutator, and the from-space holds a contiguous block of objects of which, typically, most are garbage.

The scavenge is a one-liner in the heap:

 cpp
 
 
// src/heap/heap.cc:2617
void Heap::Scavenge() {
 DCHECK_NOT_NULL(new_space());
 DCHECK(!incremental_marking()->IsMarking());

 TRACE_GC(tracer(), GCTracer::Scope::SCAVENGER_SCAVENGE);
 SetGCState(SCAVENGE);

 // Implements Cheney's copying algorithm
 scavenger_collector_->CollectGarbage();

 SetGCState(NOT_IN_GC);
}

The paging allocator

The to-space is not one big contiguous allocation region. It is a list of pages, and the allocator is a bump pointer that spills onto a new page when it runs out - filling the remainder of the old page with a filler object so that the scavenger’s page walker can still find boundaries:

 cpp
 
 
// src/heap/new-spaces.cc:722
std::optional<std::pair<Address, Address>> SemiSpaceNewSpace::Allocate(
 int size_in_bytes, AllocationAlignment alignment) {
 size_in_bytes = ALIGN_TO_ALLOCATION_ALIGNMENT(size_in_bytes);
 Address top = allocation_top();
 if (top) {
 DCHECK_SEMISPACE_ALLOCATION_TOP(allocation_top(), to_space_);
 Address high = to_space_.page_high();
 int filler_size = MainAllocator::GetFillToAlign(top, alignment);
 int aligned_size_in_bytes = size_in_bytes + filler_size;

 if (top + aligned_size_in_bytes <= high) {
 IncrementAllocationTop(high);
 return std::pair(top, high);
 }

 int remaining_in_page = static_cast<int>(high - top);
 heap()->CreateFillerObjectAt(top, remaining_in_page);
 SetAllocationTop(high);

The mutator allocates from the top of the current page; when the page runs out, the tail is filled with a filler object and a fresh page is appended.

There is a second, subtler mechanism in the same function: allocation buffer parking. When the mutator’s linear allocation buffer does not fill a page, the leftover tail is parked so a later allocation can reuse it, as long as the tail is at least 4 KB (kAllocationBufferParkingThreshold, new-spaces.h). Parking is only allowed outside a GC - during a collection the space belongs to the scavenger.

During the GC the allocator plays a different game. Because several scavenger threads allocate into the same to-space concurrently, the linear allocation buffer handed to each thread has to be limited so that two threads never think they own the same bytes:

 cpp
 
 
// src/heap/main-allocator.cc:501
 if (allocator_->in_gc()) {
 // During GC we allow multiple LABs in new space and since Allocate() above
 // returns the whole remaining page by default, we limit the size of the LAB
 // here.
 size_t used = std::max(aligned_size_in_bytes, kLabSizeInGC);
 limit = std::min(end, start + used);

Cheney’s algorithm: the worklists

Cheney’s copying algorithm is the classic answer to “copy the live set without marking it”. The scavenger implements it with two worklists - one for objects copied into the to-space, one for objects promoted to old space

and the objects on those worklists are the grey set. The root scanner supplies the initial work:

 cpp
 
 
// src/heap/scavenger.cc:280
class Scavenger {
 public:
 static constexpr int kScavengedObjectListSegmentSize = 256;

 struct ScavengedObjectListEntry {
 Tagged<HeapObject> heap_object;
 Tagged<Map> map;
 SafeHeapObjectSize size;
 };

 using ScavengedObjectList =
 ::heap::base::Worklist<ScavengedObjectListEntry,
 kScavengedObjectListSegmentSize>;

The worklist is a segmented worklist of 256-entry chunks, and each scavenger thread has a local one plus a shared global one, so threads do not contend on a single queue.

The main loop drains both worklists, and the copies it makes feed back into the worklist - that is the whole algorithm:

 cpp
 
 
// src/heap/scavenger.cc:2538
void Scavenger::Process(JobDelegate* delegate) {
 ScavengerCopiedObjectVisitor copied_object_visitor(this);
 ScavengerPromotedObjectVisitor promoted_object_visitor(this);

 bool done;
 size_t objects = 0;
 do {
 done = true;
 ScavengedObjectListEntry entry;
 while (!ShouldEagerlyProcessPromotedList() &&
 local_copied_list_.Pop(&entry)) {
 copied_object_visitor.Visit(entry.map, entry.heap_object, entry.size);
 done = false;
 if (delegate && ((++objects % kInterruptThreshold) == 0)) {
 if (!local_copied_list_.IsGlobalEmpty()) {
 delegate->NotifyConcurrencyIncrease();
 }
 }
 }

The visitor that pops an entry from the copied list walks the object’s fields, and each field that points into the from-space triggers another copy - which pushes onto the copied list. The loop ends when both lists are empty. No marking bit is ever set on a young object.

The ShouldEagerlyProcessPromotedList check is a scheduling heuristic: if the promoted list is getting long, it is drained first, because promoted objects live in old space and their fields may point at old-to-old references that other threads need.

The forwarding CAS

When the scavenger copies an object, it cannot just copy it - another thread might be copying the same object at the same time, because two different fields can point at it. V8 solves this by using the object’s map word - the word that normally holds the pointer to its map - as a forwarding address. The first thread to win a compare-and-swap owns the copy; the others read the winner’s address out of the same word:

 cpp
 
 
// src/heap/scavenger.cc:1972
 // This CAS can be relaxed because we do not access the object body if the
 // object was already copied by another thread. We only access the page header
 // of such objects and this is safe because of the memory fence after page
 // header initialization.
 if (!source->relaxed_compare_and_swap_map_word_forwarded(
 MapWord::FromMap(map), target)) {
 // Other task migrated the object.
 allocator_.FreeLast(space, target, object_size);
 const MapWord map_word = source->map_word(kRelaxedLoad);
 UpdateHeapObjectReferenceSlot(slot, map_word.ToForwardingAddress(source));
 SynchronizePageAccess(*slot);
 DCHECK(!Heap::InFromPage(*slot));
 return true;
 }

 // Copy the content of source to target. Note that we do this on purpose
 // *after* the CAS. This avoids copying of the object in the (unlikely)
 // failure case. It also helps us to ensure that we do not rely on non-relaxed
 // memory ordering for the CAS above.
 target->set_map_word(map, kRelaxedStore);
 Heap::CopyBlock(target.address() + kTaggedSize,
 source.address() + kTaggedSize,
 SafeHeapObjectSize(object_size.value() - kTaggedSize));

Three things to notice. The CAS is relaxed, because a thread that loses the race never touches the object body - it only reads the page header, which is protected by the memory fence after page header initialisation. The copy happens after the CAS, so a losing thread never does a wasted memcpy. And the losing thread still has to fix up its slot: it reads the forwarding address the winner wrote and points its slot there. That last point is the crux - after the CAS, every thread that finds the object can find its new address.

Promotion: the age mark

Not everything is copied into the to-space. Objects that are old enough get promoted to old space instead, so the young generation does not keep re-copying the same long-lived objects forever.

The age is tracked by an age mark: a single address separating the part of the space holding objects that already survived a collection from the part holding fresh allocations.

 cpp
 
 
// src/heap/new-spaces-inl.h:92
bool SemiSpaceNewSpace::ShouldBePromoted(Address object) const {
 return IsAddressBelowAgeMark(object);
}

The check is per-page, using a page flag, so that it does not need a metadata table lookup:

 cpp
 
 
// src/heap/new-spaces-inl.h:80
 if (!chunk->InNewSpaceBelowAgeMark()) {
 return false;
 }

 const Address age_mark = age_mark_;
 const bool on_age_mark_page =
 chunk->address() < age_mark &&
 age_mark <= chunk->address() + NormalPage::kPageSize;
 DCHECK_EQ(chunk->Metadata()->ContainsLimit(age_mark), on_age_mark_page);
 return !on_age_mark_page || address < age_mark;

The age mark is set at the end of every collection, to the top of the survivor region:

 cpp
 
 
// src/heap/new-spaces.cc:429
void SemiSpaceNewSpace::SetAgeMarkAndBelowAgeMarkPageFlags() {
 age_mark_ = allocation_top();

 NormalPage* current_page = to_space().first_page();

 for (size_t i = 0; i < to_space_.quarantined_pages_count_; i++) {
 DCHECK_NOT_NULL(current_page);
 current_page->SetFlagNonExecutable(MemoryChunk::NEW_SPACE_BELOW_AGE_MARK);
 current_page = current_page->next_page();
 }

So the sequence is: the survivors of collection N are copied into the bottom of the to-space; the age mark is placed at the top of that survivor region; fresh allocations then fill the space above it. At collection N+1 the from-space contains survivors (below the mark) and fresh objects (above it), and the ones below the mark are promoted.

In other words: survive one scavenge, and you are promoted.

The three-way fallback

The decision to copy or promote is not a simple either/or. EvacuateObjectDefault has three attempts, in order:

 cpp
 
 
// src/heap/scavenger.cc:2126
 if (!ShouldBePromoted(object.address())) {
 // A semi-space copy may fail due to fragmentation. In that case, we
 // try to promote the object.
 if (SemiSpaceCopyObject(map, slot, object, object_size, object_fields))
 [[likely]] {
 return RememberedSetEntryNeeded(heap_, slot);
 }
 }

 // We may want to promote this object if the object was already semi-space
 // copied in a previous young generation GC or if the semi-space copy above
 // failed.
 if (PromoteObject<THeapObjectSlot, promotion_heap_choice>(
 map, slot, object, object_size, object_fields)) [[likely]] {
 return RememberedSetEntryNeeded(heap_, slot);
 }

Copy first, promote second, copy again third, and only then give up. The reason is fragmentation: the to-space may not have a contiguous run of the right size, in which case promotion into old space (which has free lists and different size classes) succeeds where the copy failed.

The three attempts also differ in what they record. A copied object is pushed onto the copied worklist; a promoted object onto the promoted worklist; and both update the pretenuring feedback:

 cpp
 
 
// src/heap/scavenger.cc:2008
bool Scavenger::SemiSpaceCopyObject(Tagged<Map> map, THeapObjectSlot slot,
 Tagged<HeapObject> object,
 SafeHeapObjectSize object_size,
 ObjectFields object_fields) {
 static_assert(std::is_same_v<THeapObjectSlot, FullHeapObjectSlot> ||
 std::is_same_v<THeapObjectSlot, HeapObjectSlot>,
 "Only FullHeapObjectSlot and HeapObjectSlot are expected here");
 DCHECK(heap()->AllowedToBeMigrated(map, object, NEW_SPACE));
 return TryMigrateObject(
 map, slot, object, object_size, NEW_SPACE,
 [this, map, object_fields, object,
 object_size](Tagged<HeapObject> target) {
 PretenuringHandler::UpdateAllocationSite(
 heap_, map, object, object_size, &local_pretenuring_feedback_);
 copied_size_ += object_size.value();
 if (object_fields == ObjectFields::kMaybePointers) {
 local_copied_list_.Push({target, map, object_size});
 }
 });
}

Note the ObjectFields::kMaybePointers check: an object with no pointers in it - a number, a boolean - does not need to be on a worklist, because there is nothing to trace from it.

Pretenuring: allocation-site feedback

The PretenuringHandler::UpdateAllocationSite call above is more than bookkeeping. When V8 sees that objects allocated at a particular allocation site keep surviving, it can allocate them directly in old space next time, so they never have to be scavenged at all. The scavenger is where that evidence is gathered: it knows which objects survived and how big they were, and merges the feedback into the heap’s pretenuring handler at the end of the collection. The young collector is also the profiler for the old one.

Special cases: large objects and strings

Large objects. Objects too big for a page live in a separate “new large object space”, which is also flipped at the start of the scavenge. They are never copied - they are promoted immediately, by writing a self-forwarding map word:

 cpp
 
 
// src/heap/scavenger.cc:2052
bool Scavenger::HandleLargeObject(Tagged<Map> map, Tagged<HeapObject> object,
 SafeHeapObjectSize object_size,
 ObjectFields object_fields) {
 // Quick check first: A large object is the first (and only) object on a data
 // page (code pages have a different offset but are never young). This check
 // avoids the page flag access.
 if (MemoryChunk::AddressToOffset(object.address()) !=
 MemoryChunkLayout::ObjectStartOffsetInDataPage()) [[likely]] {

Strings. Three string cases are special, and all are about avoiding a copy:

A thin string points at an internalized string that is always in old space, so the scavenger points the slot at the target and drops the thin string.
A cons string whose second half is empty is a “shortcut candidate” - already flattened. The scavenger points the slot at the first half and drops the cons string:

 cpp
 
 
// src/heap/scavenger.cc:2186
 if (shortcut_strings_ &&
 object->unchecked_second() == ReadOnlyRoots(heap()).empty_string()) {
 Tagged<HeapObject> first = Cast<HeapObject>(object->unchecked_first());

 UpdateHeapObjectReferenceSlot(slot, first);

A string that can be internalized in place is treated specially so that internalization does not have to copy the characters.

The “shortcut” trick is a nice illustration of the copying collector’s second-order effects: by not copying a flattened cons string and instead splicing it out, the scavenger collapses a two-object rope into one.

The parallel scavenge

The scavenge is not single-threaded, even though it is a stop-the-world pause. The main thread scans the roots while worker threads process the old-to-new remembered set - the pages of old space that may point into the young generation. The job is posted before the root scan starts, and the main thread participates while it scans:

 cpp
 
 
// src/heap/scavenger.cc:1737
 std::unique_ptr<JobHandle> job_handle = V8::GetCurrentPlatform()->PostJob(
 v8::TaskPriority::kUserBlocking, std::move(job));

 // Iterate roots on the main thread while background threads scavenge pages.
 {
 // Copy roots.
 TRACE_GC(heap_->tracer(), GCTracer::Scope::SCAVENGER_SCAVENGE_ROOTS);

The number of scavenger tasks is derived from the size of the young generation and the number of cores, capped at eight:

 cpp
 
 
// src/heap/scavenger.cc:1579
int NumberOfScavengeTasks(Heap* heap) {
 // The maximum number of scavenger tasks including the main thread. The actual
 // number of tasks is determined at runtime.
 static constexpr int kMaxScavengerTasks = 8;

 if (!v8_flags.parallel_scavenge) {
 return 1;
 }
 const int num_scavenge_tasks =
 static_cast<int>(
 SemiSpaceNewSpace::From(heap->new_space())->TotalCapacity()) /
 MB +
 1;

Each task gets its own Scavenger object with its own local worklists, and they publish into shared global worklists at the end. The ScavengerJobTask also computes the desired concurrency dynamically - if the work turns out bigger than the number of pages suggests, it asks the job system for more workers.

One detail worth noting: the scavenger explicitly asserts that incremental marking is not running:

 cpp
 
 
// src/heap/heap.cc:2619
 DCHECK(!incremental_marking()->IsMarking());

So the classic scavenger and the concurrent marker do not run at the same time. They interleave across collections instead: after a young collection, if the old generation has consumed enough of its allocation limit, V8 starts an incremental marking cycle, which then runs with the mutator until the next collection.

Growing and shrinking the young generation

The young generation is not a fixed size. V8 grows it when a lot survives and shrinks it when the mutator is idle.

 cpp
 
 
// src/heap/heap.cc:3684
 const bool should_grow =
 (new_space_->TotalCapacity() < new_space_->MaximumCapacity()) &&
 (survived_since_last_expansion_ > new_space_->TotalCapacity());

 if (should_grow) survived_since_last_expansion_ = 0;

 if (should_grow == should_shrink) return ResizeNewSpaceMode::kNone;
 return should_grow ? ResizeNewSpaceMode::kGrow : ResizeNewSpaceMode::kShrink;
}

The growth rule is the interesting one: grow only if the surviving bytes since the last expansion exceed the whole current capacity. V8 doubles the young generation only when the survivors are comparable in size to the entire space - a sign that the workload is allocating long-lived objects and would benefit from a bigger nursery. Growth is by a factor of two (semi_space_growth_factor, default 2).

The shrink rule fires when the allocation throughput drops below 1000 bytes per millisecond - the mutator is idle - and keeps at least twice the currently-used size, floored at the minimum capacity. The GC scheduler decides when any of this runs.

The bounds come from the physical memory size:

 cpp
 
 
// src/heap/heap.cc:4824
// static
size_t Heap::DefaultMinSemiSpaceSize() {
 return RoundUp(512 * KB, NormalPage::kPageSize);
}

// static
size_t Heap::DefaultMaxSemiSpaceSize(uint64_t physical_memory) {
 if (v8_flags.minor_ms) {
 static constexpr size_t kMinorMsMaxCapacity = 72 * MB;
 return RoundUp(kMinorMsMaxCapacity, NormalPage::kPageSize);
 }

So a semi-space starts at 512 KB and can grow to 32 MB (72 MB with the minor mark-sweep collector, 8 MB on low-end Android).

Trade-offs

What it buys. A young collection is a copy of the live set and nothing else. No marking, no sweeping, no free-list maintenance. The cost is proportional to what survives, not to what was allocated, and the swap that starts the collection is two pointer writes.

What it costs.

Copying is not free. Every survivor is memcpy’d. A workload where most objects survive has paid twice: once to copy, once to collect.
Fragmentation. The to-space is a bump allocator, so a large object can fail to fit and force a promotion. The three-way fallback in EvacuateObjectDefault exists because of this.
Promotion is not always right. An object promoted too early occupies old space, where the mark-compact collector will trace it forever.
The pause is still a pause. The scavenger is a stop-the-world event, even though its work is parallelised.

The bottom line

The scavenger is a copying collector with a two-pointer flip. Live young objects are copied from the from-space into the to-space with Cheney’s algorithm; dead ones are not copied, and the whole from-space becomes free memory in one pointer swap.

The two ideas that make it work in practice are the forwarding CAS on the map word - which lets several threads copy concurrently without locks and without double-copying - and the age mark, which decides when an object has earned a place in old space.

The mental model: the young generation is a nursery, and the scavenger moves the survivors into bigger pots.

The thing people get wrong

“The scavenger is a stop-the-world pause, so it is expensive.” It is a stop-the-world pause, but the work inside it is proportional to the live set and is spread across up to eight threads while the main thread scans roots. A young collection in V8 is typically single-digit milliseconds.

The opposite misconception is also common: “the scavenger frees the young generation, so memory usage drops.” It does not necessarily. The from-space is reused, not returned to the OS - the same pages come back as the to-space. Memory only drops when V8 shrinks the young generation or when the old generation is collected.

And the third: “objects are promoted when they get old.” They are promoted when they survive. The age mark is not a clock; it is a line drawn across the to-space at the end of each collection, and everything below it

everything copied out of the previous from-space - is promoted at the next one.

The Write Barrier: How V8 Knows Where a Moved Object Used to Live

Jay Hubbert — Wed, 21 Oct 2026 18:20:00 +0000

TL;DR: V8’s write barrier is not one thing. It is a four-tier machine

inline fast path, deferred out-of-line path, shared slow path, C++ slow path - that does up to three jobs at once: remembering old-to-new references for the generational collector, marking the value and preventing black-to-white references during incremental marking, and recording the slot of an old-to-old reference so that a compacting GC can find it again and rewrite it. The compacting part does not remember the old address of the moved object; it remembers where the pointer lives.

Every time V8’s mutator writes a heap pointer into a heap object, the garbage collector has to hear about it. Not always - but often enough that the “often enough” case has to be nearly free.

V8’s answer is a layered barrier that most stores never pay for. The interesting design is not the layering; it is the third job, the one that exists only because V8 has a moving collector.

Three jobs, one barrier

V8 ships a readme for the barrier, and it is worth reading before the code:

 cpp
 
 
// src/heap/WRITE_BARRIER.md:3
V8 uses a write barrier to inform the GC about changes to the heap by the mutator.
A write barrier is emitted for heap stores like `host.field = value`.
The write barrier is required for multiple purposes:
* Records old-to-new references for the generational GC to work.
* During marking it prevents black-to-white references during incremental/concurrent marking.
* During marking it records old-to-old references (pointers to objects on evacuation candidates)

Three jobs:

Generational. If an old object points at a young object, the young object has to survive the next scavenge, so the barrier records the slot.
Marking. During incremental or concurrent marking, the tri-colour invariant says a black object must not point at a white one. The barrier marks the value and, when necessary, shades the host.
Evacuation slot recording. If the value lives on a page the compacting collector wants to move, the collector needs to find every reference to it. The barrier records the slot.

The first two are well known. The third is where the “how does V8 know where a moved object used to live” question is answered.

The four-tier structure

The barrier is split into four tiers - inline fast path, deferred out-of-line path, shared slow path, C++ slow path - and the split is the same in the C++ path, in CSA, and in TurboFan. Tiers 1 and 2 are emitted per call site: the fast path is inline in the store, the deferred path is a branch target nearby. Tier 3 is a shared routine written in CSA. Tier 4 is C++ that may malloc.

The C++ entry point shows the shape of the whole thing:

 cpp
 
 
// src/heap/heap-write-barrier-inl.h:51
// static
void WriteBarrier::CombinedWriteBarrierInternal(Tagged<HeapObject> host,
 HeapObjectSlot slot,
 Tagged<HeapObject> value,
 WriteBarrierMode mode) {
 DCHECK_EQ(mode, UPDATE_WRITE_BARRIER);

 if constexpr (v8_flags.sticky_mark_bits.value()) {
 CombinedWriteBarrierInternalForStickyMarkbits(host, slot, value, mode);
 return;
 }

 MemoryChunk* host_chunk = MemoryChunk::FromHeapObject(host);
 // Fast path: Marking is off and the host objects is either in the young
 // generation or shared space, for which we don't require remembered sets.
 if (!host_chunk->PointersFromHereAreInteresting()) [[likely]] {
 return;
 }

 // Either marking is on, or the host objects is in the old (non-shared)
 // generation for which we record remembered sets.

 MemoryChunk* value_chunk = MemoryChunk::FromHeapObject(value);
 // Old to old writes can bail out when marking is off.
 if (!value_chunk->PointersToHereAreInteresting()) {
 return;
 }

 CombinedWriteBarrierInternalSlow(host, host_chunk, slot, value, value_chunk);
}

Two loads of a page-header flag and two predictable branches. That is the cost of the barrier for a store that does not need one.

The fast path: two page flags

The flags are per-page, not per-object, and they answer two questions:

kPointersFromHereAreInterestingMask - does this page contain objects whose outgoing pointers the GC cares about? False for young-generation pages and read-only pages.
kPointersToHereAreInterestingMask - does this page contain objects the GC might need to find references to? False for read-only pages and, during marking, for pages that are already black.

 cpp
 
 
// src/heap/memory-chunk.h:113
 static constexpr MainThreadFlags kAllFlagsMask = ~MainThreadFlags(NO_FLAGS);
 static constexpr MainThreadFlags kPointersToHereAreInterestingMask =
 POINTERS_TO_HERE_ARE_INTERESTING;
 static constexpr MainThreadFlags kPointersFromHereAreInterestingMask =
 POINTERS_FROM_HERE_ARE_INTERESTING;

The page granularity is what makes this cheap: a whole 256 KB page of young objects answers “not interesting” with a single flag test, so a store into a young object needs no barrier at all.

There is a subtlety in the fast path above that is easy to miss. The second check - “old to old writes can bail out when marking is off” - holds only because when marking is off there is nothing to mark and nothing to rewrite. During marking, an old-to-old write must be examined, because the value might now be on an evacuation candidate page.

The generational barrier: old to new

When the host is old and the value is young, the slot has to be recorded so the scavenger can find the young object through the old one. This is the OLD_TO_NEW remembered set, and it is what the scavenger reads.

 cpp
 
 
// src/heap/heap-write-barrier.cc:408
void WriteBarrier::GenerationalBarrierSlow(Tagged<HeapObject> host,
 Address slot,
 Tagged<HeapObject> value) {
 const LocalHeap* local_heap = LocalHeap::Current();
 MemoryChunk* host_chunk = MemoryChunk::FromHeapObject(host);
 MutablePage* host_page =
 SbxCast<MutablePage>(host_chunk->Metadata(local_heap->heap()->isolate()));
 if (local_heap->is_main_thread()) {
 RememberedSet<OLD_TO_NEW>::Insert<AccessMode::NON_ATOMIC>(
 host_page, host_chunk->Offset(slot));
 } else {
 RememberedSet<OLD_TO_NEW_BACKGROUND>::Insert<AccessMode::ATOMIC>(
 host_page, host_chunk->Offset(slot));
 }
}

Note that there are two remembered sets, not one: the main thread uses a non-atomic insert into OLD_TO_NEW, background threads an atomic insert into OLD_TO_NEW_BACKGROUND. The scavenger scans both.

The marking barrier: keeping the tri-colour invariant

During incremental or concurrent marking, the barrier must mark the value grey so it gets traced, and shade the host if the host is black and the value is white.

 cpp
 
 
// src/heap/marking-barrier-inl.h:20
template <typename TSlot, RecordYoungSlot kRecordYoung>
void MarkingBarrier::Write(Tagged<HeapObject> host, TSlot slot,
 Tagged<HeapObject> value) {
 DCHECK(IsCurrentMarkingBarrier(host));
 DCHECK(is_activated_ || shared_heap_worklists_.has_value());
 DCHECK(MemoryChunk::FromHeapObject(host)->IsMarking());

 MarkValue(host, value);

 // When recording slots to young pointers, we need to call RecordSlot even if
 // IsCompacting() returns true. This is because IsCompacting() simply returns
 // false when there are no evacuation candidates. New space pages are not
 // considered evacuation candidates and may still be relocated.
 if (slot.address() &&
 (static_cast<bool>(kRecordYoung) || IsCompacting(host))) {
 MarkCompactCollector::RecordSlot<TSlot, kRecordYoung>(host, slot, value);
 }
}

MarkValue handles the tri-colour logic (mark the value, and if the host is black and the value is white, shade the host). The RecordSlot call is the third job, and it is conditional on IsCompacting(host) - the host’s page must be one the compacting collector intends to move.

The evacuation barrier: how V8 knows where a moved object used to live

Here is the mechanism, and it is not what most people assume.

The barrier does not store the old address of the moved object. It stores the offset of the slot - the position of the pointer field inside the host page - in the OLD_TO_OLD remembered set.

 cpp
 
 
// src/heap/mark-compact-inl.h:73
 const MemoryChunk* value_chunk = MemoryChunk::FromHeapObject(value);
 if (!value_chunk->IsEvacuationCandidate() &&
 (!static_cast<bool>(kRecordYoung) ||
 !HeapLayout::InYoungGeneration(value_chunk, value))) {
 return;
 }

Note the early-out: the slot is only recorded if the value is on an evacuation candidate page. If the value is in a page that will not move, there is nothing to rewrite later, so nothing is recorded. The insert itself picks the remembered set that matches the kind of space the value is in:

 cpp
 
 
// src/heap/mark-compact-inl.h:97
 } else if (V8_LIKELY(!value_page->is_writable_shared()) ||
 host_page->heap()->isolate()->is_shared_space_isolate()) {
 DCHECK_EQ(host_page->heap(), value_page->heap());
 RememberedSet<OLD_TO_OLD>::Insert<AccessMode::ATOMIC>(
 host_page, host_chunk->Offset(slot.address()));

Now the compaction side. At the end of the mark-compact cycle, the collector walks the OLD_TO_OLD set and rewrites each recorded slot, and UpdateSlot does the actual rewrite by reading the old address out of the slot and following the forwarding pointer stored in the old object’s map word:

 cpp
 
 
// src/heap/mark-compact.cc:4423
 if (HeapLayout::InReadOnlySpace(heap_obj)) return;
 MapWord map_word = heap_obj->map_word(kRelaxedLoad);
 if (!map_word.IsForwardingAddress()) return;
 DCHECK_IMPLIES((!v8_flags.minor_ms && !Heap::InFromPage(heap_obj)),
 MarkCompactCollector::IsOnEvacuationCandidate(heap_obj) ||
 MemoryChunk::FromHeapObject(heap_obj)
 ->Metadata()
 ->evacuation_was_aborted());
 typename TSlot::TObject target = MakeSlotValue<TSlot, reference_type>(
 map_word.ToForwardingAddress(heap_obj));
 // Needs to be atomic for map space compaction: This slot could be a map
 // word which we update while loading the map word for updating the slot
 // on another page.
 slot.Relaxed_Store(target);

So the flow is: the barrier remembers where the pointer is; the collector later reads what the pointer was from that slot; the moved object carries its new address in its own map word as a forwarding pointer; and the slot is overwritten with the new address.

The object itself does the remembering. The moving collector already has to write a forwarding address into every object it moves, so the “where did this object used to live” question is answered by the object, not by the barrier.

The remembered set is a bitmap, not a list

One more thing makes this affordable. The remembered set is not a list of slot addresses. It is a bitmap, one bit per pointer-sized slot in the page:

 cpp
 
 
// src/heap/base/basic-slot-set.h:277
 static constexpr int kCellsPerBucket = 32;
 static constexpr int kCellsPerBucketLog2 = 5;
 static constexpr int kCellSizeBytesLog2 = 2;
 static constexpr int kCellSizeBytes = 1 << kCellSizeBytesLog2;
 static constexpr int kBitsPerCell = 32;
 static constexpr int kBitsPerCellLog2 = 5;
 static constexpr int kBitsPerBucket = kCellsPerBucket * kBitsPerCell;
 static constexpr int kBitsPerBucketLog2 =
 kCellsPerBucketLog2 + kBitsPerCellLog2;

A bucket is 32 cells of 32 bits, i.e. 1024 bits, covering 1024 slots. With V8’s default 256 KB page and 8-byte tagged slots, a page has 32768 slots, so a fully-populated slot set is 32768 bits - 4 KB - for a 256 KB page. One bit per slot.

This is also why the CSA implementation can do the insert without any allocation in the common case: the slot set is allocated lazily per page, and the insert is a bit-set.

When the barrier is skipped

The barrier is elided in several cases: storing a Smi, storing a read-only object, and storing into the most recent young allocation - an “initializing store”, where the host was allocated in the young generation and no GC point has occurred since.

The third rule is the clever one, and it is safe for a non-obvious reason:

 cpp
 
 
// src/heap/WRITE_BARRIER.md:26
None of the three write barrier kinds are necessary for such stores:
* **Old-to-new (generational) barrier:** Not needed because the host object is itself young, so there is no old-to-new reference to record.
* **Old-to-old (evacuation) barrier:** Not needed because the host object is young, so there is no old-to-old slot to track. The GC can still relocate young objects during a GC; new-to-new slots are discovered by scanning the young generation during the atomic GC pause. This is cheap because the young generation is usually small relative to the full heap size. Note that old-to-new references are still recorded by the generational barrier even during incremental marking. That way we discover all references to young objects.
* **Marking barrier:** This is the trickiest case. Concurrent marking bails out of tracing objects that reside in the current new space LAB (linear allocation buffer) and pushes them into an "on hold" queue. This prevents such objects from becoming black — they remain grey. Grey objects are marked but are also contained in the worklist - so they will be traced at some point in the future. All of this means that the host object for such cases can never be black - so we also do not need a WB to prevent black-to-white references here. This is also where the *most recently allocated object* limitation comes from.

Read that third bullet carefully. The reason a freshly allocated object needs no marking barrier is not that it is young. It is that concurrent marking refuses to blacken objects in the current linear allocation buffer - they go on an “on hold” queue and stay grey. A grey host can never violate the tri-colour invariant, because grey means “will be traced again”.

The C++ side has the same rules, and the debug build checks them:

 cpp
 
 
// src/heap/heap-write-barrier-inl.h:525
// static
template <typename HostType, typename ValueType>
bool WriteBarrier::IsRequiredCommon(HostType host, ValueType value) {
 if (IsSmi(value)) {
 return false;
 }
 if (value.IsCleared()) {
 return false;
 }
 Tagged<HeapObject> target = value.GetHeapObject();
 if (ReadOnlyHeap::Contains(target)) {
 return false;
 }
 if constexpr (std::is_same_v<HostType, const HeapObject*>) {
 return !IsMostRecentYoungAllocation(host->address());
 } else {
 return !IsMostRecentYoungAllocation(host.address());
 }
}

SKIP_WRITE_BARRIER is a mode that a caller asserts; in a verification build, VerifySkipWriteBarrier checks the assertion and fails the process if it is wrong.

How the barrier is generated: CSA and TurboFan

The shared slow path is written in CSA, in WriteBarrierCodeStubAssembler. The generational insert is the interesting part, because it is the one that has to touch a per-page bitmap:

 cpp
 
 
// src/builtins/builtins-internal-gen.cc:175
 TNode<IntPtrT> slot_offset = IntPtrSub(slot, chunk);
 TNode<IntPtrT> num_buckets_address =
 IntPtrSub(slot_set, IntPtrConstant(SlotSet::kNumBucketsSize));
 TNode<IntPtrT> num_buckets = UncheckedCast<IntPtrT>(
 Load(MachineType::Pointer(), num_buckets_address, IntPtrConstant(0)));

 // Load bucket
 TNode<IntPtrT> bucket =
 LoadBucket(slot_set, slot_offset, num_buckets, &slow_path);

 // Update cell
 SetBitInCell(bucket, slot_offset);
 Goto(&next);

 BIND(&slow_path);
 {
 TNode<ExternalReference> function =
 ExternalConstant(ExternalReference::insert_remembered_set_function());
 CallCFunctionWithCallerSavedRegisters(
 function, MachineTypeOf<Int32T>::value, fp_mode,
 std::make_pair(MachineTypeOf<IntPtrT>::value, page),
 std::make_pair(MachineTypeOf<IntPtrT>::value, slot_offset));
 Goto(&next);
 }

The slow path is the C++ Heap::InsertIntoRememberedSetFromCode, the only tier that may have to allocate the slot set for a page.

The marking side of the CSA barrier encodes the evacuation-candidate test as a single fused condition:

 cpp
 
 
// src/builtins/builtins-internal-gen.cc:467
 void IsValueUnmarkedOrRecordSlot(TNode<IntPtrT> value, Label* true_label,
 Label* false_label) {
 // This code implements the following condition:
 // IsUnmarked(value) ||
 // OnEvacuationCandidate(value) &&
 // !SkipEvacuationCandidateRecording(value)

 // 1) IsUnmarked(value) || ....
 GotoIf(IsUnmarked(value), true_label);

 // 2) OnEvacuationCandidate(value) &&
 // !SkipEvacuationCandidateRecording(value)
 GotoIfNot(IsPageFlagSet(value, MemoryChunk::kEvacuationCandidateMask),
 false_label);

If the value is unmarked, the barrier must run (to mark it). If it is marked but on an evacuation candidate page, the barrier must run (to record the slot). Otherwise it can be skipped entirely.

TurboFan emits the barrier as a dedicated machine opcode, kArchAtomicStoreWithWriteBarrier, whose inline fast path is:

 cpp
 
 
// src/compiler/backend/x64/code-generator-x64.cc:2136
 if (mode > RecordWriteMode::kValueIsPointer) {
 __ JumpIfSmi(value, ool->exit());
 }
#if V8_ENABLE_STICKY_MARK_BITS_BOOL
 __ CheckPageFlag(object, scratch0, MemoryChunk::kIncrementalMarking,
 not_zero, ool->stub_call());
 __ CheckMarkBit(object, scratch0, scratch1, carry, ool->entry());
#else // !V8_ENABLE_STICKY_MARK_BITS_BOOL
 static_assert(WriteBarrier::kUninterestingPagesCanBeSkipped);
 __ CheckPageFlag(object, scratch0,
 MemoryChunk::kPointersFromHereAreInterestingMask,
 not_zero, ool->entry());
#endif // !V8_ENABLE_STICKY_MARK_BITS_BOOL
 __ bind(ool->exit());

Three things happen here, in order: the store itself is emitted (the EmitTSANAwareStore call above it), a Smi value short-circuits to the exit label, and then the page flag decides whether to fall into the out-of-line OutOfLineRecordWrite block. That block checks the value page flag - the POINTERS_TO_HERE_ARE_INTERESTING test - and, if the value is uninteresting, jumps back out without doing any work.

That is the whole barrier for a typical store: a Smi test, a page flag test, and a not-taken branch.

The sandbox: external and trusted pointers

With the sandbox enabled, some heap fields do not hold a heap pointer at all. They hold an index into a side table of external pointers, or a tagged indirect pointer into the trusted space. Those need their own barriers, because the GC has to mark the table entry and not the slot.

 cpp
 
 
// src/heap/heap-write-barrier.cc:143
void WriteBarrier::MarkingSlow(Tagged<HeapObject> host,
 ExternalPointerSlot slot,
 ExternalPointerHandle handle) {
#ifdef V8_COMPRESS_POINTERS
 if (!slot.HasExternalPointerHandle()) return;

 DCHECK_EQ(handle, slot.Relaxed_LoadHandle());

 MarkingBarrier* marking_barrier = CurrentMarkingBarrier(host);
 IsolateForPointerCompression isolate(marking_barrier->heap()->isolate());

 ExternalPointerTable& table =
 isolate.GetExternalPointerTableFor(slot.tag_range());
 ExternalPointerTable::Space* space =
 isolate.GetExternalPointerTableSpaceFor(slot.tag_range(), host.address());
 DCHECK(!space->is_internal_read_only_space());

 table.Mark(space, handle, slot.address(), slot.tag_range());

Trusted (indirect) pointers get their own TurboFan opcode, kArchStoreTrustedWithWriteBarrier, because the slot holds a tagged index rather than a pointer.

Setting a map is a write too

Changing an object’s map is a pointer write, and it goes through the barrier like any other - which matters, because the map word is where a forwarding pointer is stored during compaction.

 cpp
 
 
// src/objects/heap-object-set-map-inl.h:100
 set_map_word(value, order);
 Heap::NotifyObjectLayoutChangeDone(this);
#ifndef V8_DISABLE_WRITE_BARRIERS
 if (emit_write_barrier == EmitWriteBarrier::kYes) {
 WriteBarrier::ForValue(this, MaybeObjectSlot(map_slot()), value,
 UPDATE_WRITE_BARRIER);
 } else {

There is also an explicit set_map_safe_transition_no_write_barrier for callers who know the transition is safe.

Trade-offs

What it buys. The generational collector does not have to scan the whole old generation to find its young objects. Incremental and concurrent marking can run without stopping the world. Compacting can move objects without scanning for references.

What it costs.

Every store pays something. Even the fast path is a flag test, and the flag test needs the page header, which is a cache miss away from the object.
The remembered sets are memory. One bit per slot per page, times the number of pages, times the number of remembered set kinds.
The barrier is a correctness hazard. A missed barrier is not a slow path, it is a corrupted heap or a lost object. That is why V8_VERIFY_WRITE_BARRIERS exists and why SKIP_WRITE_BARRIER is a mode the runtime asserts rather than a flag it trusts.
The skipping rules are subtle. “Most recent young allocation” is a property of the allocator, not of the object, and getting it wrong is a use-after-free.

The bottom line

V8’s write barrier is not a “tell the GC that something changed” hook. It is three specific, independently-switchable mechanisms sharing one fast path: remember old-to-new edges so the scavenger can find young objects; maintain the tri-colour invariant during marking so marking can be incremental; and remember slots whose values might move so the compactor can rewrite them.

The deep trick is that the third one does not remember addresses at all. It remembers a bit in a bitmap saying “there is a pointer in this slot”, and the moving object remembers where it went by writing a forwarding pointer into its own map word. Between them the barrier and the object hold all the information, and neither holds the “before” address. The concurrent marker is what the marking half of this exists to feed.

The thing people get wrong

“The write barrier records the old address of the object so the GC can update the reference.” It does not. The barrier records the slot - a bit in a per-page bitmap saying “this field holds a pointer that might need rewriting”. The old address is still sitting in that slot, and the collector reads it out at compaction time, follows the forwarding pointer in the old object’s map word, and overwrites the slot.

That distinction explains why the remembered set can be a bitmap, and why the barrier has to fire on a write even when the value does not change: if the value is on an evacuation candidate page, the collector must know about that slot even if the pointer is identical to what was there before - because the object it points at is about to move.

The other thing people get wrong: “the write barrier is only about the generational GC.” Two of its three jobs only exist during incremental or concurrent marking, and the third only during a compacting GC. The generational part is always on; the expensive part is conditional, which is why the fast path is two flags and a branch.