Root Scanning: How V8 Finds Every Pointer to a Live Object

Jay Hubbert — Thu, 22 Oct 2026 10:40:00 +0000

TL;DR: A mark-sweep collector is only as good as its root set. V8’s root set is enumerated by one function, Heap::IterateRoots, which walks a fixed list of root locations: the isolate’s roots table, the builtins, the compilation cache, traced handles, global handles, handle scopes, persistent handles, eternal handles, microtask queues and the embedder’s registered strong roots. On top of that it scans the machine stack conservatively, looking at every word that could be a pointer - which is why a garbage collector can keep an object alive that JavaScript can no longer reach. And in the other direction, the old-to-new remembered set records the slots where an old object points at a young one, so a scavenger knows which old pages to look at.

Marking a heap is easy. The hard part is knowing where to start. A mark sweep collector needs a set of roots: locations outside the heap that contain pointers into the heap. Everything reachable from a root is live; everything else is garbage.

The roots fall into two very different categories, and conflating them is the source of most misunderstandings about V8’s GC:

Precise roots. A location that V8 knows contains a pointer, because V8 put it there. The roots table, handle scopes, global handles. Scanning these is exact.
Conservative roots. A region of memory that might contain a pointer. The machine stack, principally. Scanning these is a heuristic, and it produces false positives.

The visitor

Both kinds of roots are visited through the same interface. RootVisitor is an abstract class in src/objects/visitors.h:

 cpp
 
 
// src/objects/visitors.h:66
class RootVisitor {
 public:
 virtual ~RootVisitor() = default;

 // Visits a contiguous arrays of pointers in the half-open range
 // [start, end). Any or all of the values may be modified on return.
 virtual void VisitRootPointers(Root root, const char* description,
 FullObjectSlot start, FullObjectSlot end) = 0;

 // Handy shorthand for visiting a single pointer.
 virtual void VisitRootPointer(Root root, const char* description,
 FullObjectSlot p) {
 VisitRootPointers(root, description, p, p + 1);
 }

Note the Root enum parameter. It is not decoration: it names which kind of root is being visited (kStackRoots, kGlobalHandles, kHandleScope, kBuiltins, kTracedHandles, …), and the visitor uses it to behave differently. The conservative stack visitor, for instance, uses it to decide whether a found object is in the young generation.

The Root enum is a flat list generated from a macro, and it doubles as the synchronisation tag set used by the serializer:

 cpp
 
 
// src/objects/visitors.h:57
enum class Root {
#define DECLARE_ENUM(enum_item, ignore) enum_item,
 ROOT_ID_LIST(DECLARE_ENUM)
#undef DECLARE_ENUM
 kNumberOfRoots
};

The MarkCompactCollector supplies the implementation that actually marks:

 cpp
 
 
// src/heap/mark-compact-inl.h:136
void RootMarkingVisitor::MarkObjectByPointer(Root root, FullObjectSlot p) {
 Tagged<Object> object = *p;
#ifdef V8_ENABLE_DIRECT_HANDLE
 if (object.ptr() == kTaggedNullAddress) return;
#endif
 if (!IsHeapObject(object)) return;
 Tagged<HeapObject> heap_object = Cast<HeapObject>(object);
 const auto target_worklist =
 MarkingHelper::ShouldMarkObject(collector_->heap(), heap_object);
 if (!target_worklist) {
 return;
 }
 collector_->MarkRootObject(root, heap_object, target_worklist.value());
}

ShouldMarkObject returns std::nullopt for objects that are always live - read-only space objects, black-allocated pages - which do not need to be marked or pushed onto a worklist.

The roots table: V8’s own permanent objects

Before anything else, there is the set of objects that V8 itself needs: undefined, null, the empty string, the Object prototype, the array prototype, and a few hundred more. These live in a table owned by the isolate:

 cpp
 
 
// src/roots/roots.h:666
class RootsTable {
 public:
 static constexpr size_t kEntriesCount =
 static_cast<size_t>(RootIndex::kRootListLength);

 RootsTable() : roots_{} {}

 inline bool IsRootHandleLocation(Address* handle_location,
 RootIndex* index) const;

Each entry is a single tagged pointer, so scanning the whole table is a linear walk over an array of words. Some of the entries are special: the single-character string cache is a run of consecutive roots, and the “immortal immovable” roots at the front of the table can be treated as constants by generated code.

One function to enumerate them all

Heap::IterateRoots is the centre of the whole thing. It takes a RootVisitor* and a set of SkipRoot options, and it visits everything:

 cpp
 
 
// src/heap/heap.cc:4565
void Heap::IterateRoots(RootVisitor* v, base::EnumSet<SkipRoot> options,
 IterateRootsMode roots_mode) {
 v->VisitRootPointers(Root::kStrongRootList, nullptr,
 roots_table().strong_roots_begin(),
 roots_table().strong_roots_end());
 v->Synchronize(VisitorSynchronization::kStrongRootList);

 isolate_->bootstrapper()->Iterate(v);
 v->Synchronize(VisitorSynchronization::kBootstrapper);
 Relocatable::Iterate(isolate_, v);
 v->Synchronize(VisitorSynchronization::kRelocatable);
 isolate_->debug()->Iterate(v);
 v->Synchronize(VisitorSynchronization::kDebug);

 isolate_->compilation_cache()->Iterate(v);
 v->Synchronize(VisitorSynchronization::kCompilationCache);

and then, further down, the transient roots:

 cpp
 
 
// src/heap/heap.cc:4614
 if (!options.contains(SkipRoot::kUnserializable)) {
 if (!options.contains(SkipRoot::kTracedHandles)) {
 // Young GCs always skip traced handles and visit them manually.
 DCHECK(!options.contains(SkipRoot::kOldGeneration));

 isolate_->traced_handles()->Iterate(v);
 }

 if (!options.contains(SkipRoot::kGlobalHandles)) {
 // Young GCs always skip global handles and visit them manually.
 DCHECK(!options.contains(SkipRoot::kOldGeneration));

 if (options.contains(SkipRoot::kWeak)) {
 isolate_->global_handles()->IterateStrongRoots(v);
 } else {
 isolate_->global_handles()->IterateAllRoots(v);
 }
 }

The SkipRoot options are why this function can serve both a major GC and a minor GC. A scavenger does not need the old generation’s roots, so it passes SkipRoot::kOldGeneration and the global handles are visited separately, by the young-generation-specific path.

There is one more root source here that is easy to miss: the embedder’s registered strong roots.

 cpp
 
 
// src/heap/heap.cc:4671
 // Iterate over other strong roots (currently only identity maps and
 // deoptimization entries).
 for (StrongRootsEntry* current = strong_roots_head_; current;
 current = current->next) {
 v->VisitRootPointers(Root::kStrongRoots, current->label, current->start,
 current->end);
 }

A StrongRootsEntry is a labelled range of slots that an embedder (Chrome’s Blink, for instance) has told V8 about. It is the mechanism by which objects that are not in V8’s heap at all - but are referenced from Blink’s - stay alive.

Handle scopes: the stack of handles

The most common kind of precise root is the local handle. When C++ code in V8 needs to hold a reference to an object across an allocation, it puts it in a handle:

 cpp
 
 
// include/v8-local-handle.h:112
class V8_EXPORT V8_NODISCARD HandleScope {
 public:
 V8_INLINE explicit HandleScope(Isolate* isolate);

 V8_INLINE ~HandleScope();

A HandleScope is a stack discipline. Entering one saves the current handle allocation pointer; leaving it restores it, so every handle created inside the scope is popped in one go. The handles themselves live in blocks of kHandleBlockSize slots, allocated from the isolate’s handle scope implementer.

The GC scans the live handles by walking those blocks:

 cpp
 
 
// src/handles/handle-scope-implementer.cc:76
void HandleScopeImplementer::IterateThis(RootVisitor* v) {
#ifdef DEBUG
 bool found_block_before_persistent = false;
#endif
 // Iterate over all handles in the blocks except for the last.
 for (int i = static_cast<int>(blocks()->size()) - 2; i >= 0; --i) {
 Address* block = blocks()->at(i);

The loop stops at size() - 2 because the last block is special: only the part of it up to the current allocation pointer contains live handles. The rest is uninitialised memory. And the very last part of the iteration handles the current block:

 cpp
 
 
// src/handles/handle-scope-implementer.cc:107
 // Iterate over live handles in the last block (if any).
 if (!blocks()->empty()) {
 v->VisitRootPointers(Root::kHandleScope, nullptr,
 FullObjectSlot(blocks()->back()),
 FullObjectSlot(handle_scope_data_.next));
 }

handle_scope_data_.next is the current allocation pointer - the high-water mark. Everything between it and the end of the block is garbage and is not scanned.

Global handles: nodes, not slots

A global handle outlives the scope that created it, so it cannot live in the handle scope’s block stack. V8 gives each global handle its own node in a node space, and the handle the embedder holds is a pointer to the node:

 cpp
 
 
// src/handles/global-handles.cc:624
IndirectHandle<Object> GlobalHandles::Create(Tagged<Object> value) {
 GlobalHandles::Node* node = regular_nodes_->Allocate();
 if (NeedsTrackingInYoungNodes(value, node)) {
 young_nodes_.push_back(node);
 node->set_in_young_list(true);
 }
 return node->Publish(value);
}

Nodes are grouped into blocks, and blocks are linked into a list. That indirection is what lets the GC rewrite a global handle’s target when compaction moves the object, and it lets V8 track weak handles, phantom handles and their callback parameters in the same structure.

There is also a separate list of young nodes, so the scavenger does not have to walk every global handle to find the ones pointing into the young generation.

Traced handles, eternal handles and persistent handles

Three more root sources, each with a different lifetime policy.

Traced handles are for embedders that want a root that the GC can move but that the embedder keeps in its own data structure. They are stored in their own blocks and iterated explicitly:

 cpp
 
 
// src/handles/traced-handles.cc:702
void TracedHandles::Iterate(RootVisitor* visitor) {
 for (auto* block : blocks_) {
 for (auto* node : *block) {
 if (!node->is_in_use()) continue;

 visitor->VisitRootPointer(Root::kTracedHandles, nullptr,
 node->location());
 }
 }
}

Eternal handles are roots that are never collected and never moved. They are the mechanism behind v8::Isolate::GetCurrentContext()-style APIs that must stay valid forever.

Persistent handles are the C++ side of the same idea: v8::Persistent objects that the embedder stores wherever it likes, and that V8 scans through the isolate’s persistent handle list.

The conservative stack scan

And then there is the machine stack. V8 does not know every place in the C++ stack where an object pointer might be sitting, so it scans the stack conservatively: it treats every aligned word as a candidate pointer.

 cpp
 
 
// src/heap/conservative-stack-visitor-inl.h:132
template <typename ConcreteVisitor>
void ConservativeStackVisitorBase<ConcreteVisitor>::VisitPointer(
 const void* pointer) {
 auto address = reinterpret_cast<Address>(const_cast<void*>(pointer));
#ifdef V8_COMPRESS_POINTERS
 V8HeapCompressionScheme::ProcessIntermediatePointers(
 address,
 [this](Address ptr) { VisitConservativelyIfPointer(ptr, cage_base_); });

“Intermediate pointers” is a nice detail: a pointer to the middle of a string or a typed array is also a candidate, so V8 tries both the base address and the “interior” form.

The hard part is turning a candidate address back into an object. V8 first checks that the address is in a page the heap owns, then walks the page forward looking for the object that contains it:

 cpp
 
 
// src/heap/conservative-stack-visitor-inl.h:66
Address ConservativeStackVisitorBase<ConcreteVisitor>::FindBasePtr(
 Address maybe_inner_ptr, PtrComprCageBase cage_base) const {
#ifdef V8_COMPRESS_POINTERS
 DCHECK(IsInterestingCage(cage_base));
#endif // V8_COMPRESS_POINTERS
 // Check if the pointer is contained by a normal or large page owned by this
 // heap. Bail out if it is not.
 // TODO(379788114): Consider introducing a bloom filter for pages.
 const MemoryChunk* chunk =
 allocator_->LookupChunkContainingAddressInSafepoint(maybe_inner_ptr);
 if (chunk == nullptr) {
 return kNullAddress;
 }

and then:

 cpp
 
 
// src/heap/conservative-stack-visitor-inl.h:101
 // Otherwise, we have a pointer inside a normal page.
 const NormalPage* page = static_cast<const NormalPage*>(chunk_metadata);
 // Try to find the address of a previous valid object on this page.
 Address base_ptr =
 MarkingBitmap::FindPreviousValidObject(page, maybe_inner_ptr);
 // Iterate through the objects in the page forwards, until we find the object
 // containing maybe_inner_ptr.

FindPreviousValidObject uses the marking bitmap to find the closest object start at or below the candidate address, then the loop walks forward object-by-object using the map’s instance size. It is a genuinely conservative algorithm: it does not verify that the address is a pointer, only that it falls inside a known object.

The result is then reported to the root visitor as a stack root:

 cpp
 
 
// src/heap/conservative-stack-visitor-inl.h:198
 // Proceed with inner-pointer resolution.
 Address base_ptr = FindBasePtr(address, cage_base);
 if (base_ptr == kNullAddress) {
 return;
 }
 Tagged<HeapObject> obj = HeapObject::FromAddress(base_ptr);
 Tagged<Object> root = obj;
 DCHECK_NOT_NULL(root_visitor_);
 root_visitor_->VisitRootPointer(Root::kStackRoots, nullptr,
 FullObjectSlot(&root));

Why the false positives happen

A conservative scan of the machine stack will find integers that happen to look like heap addresses. Any 64-bit value that happens to fall inside a heap page and inside a valid object is treated as a pointer to that object, and that object is marked live.

This is not a bug - it is the price of not knowing where the pointers are. The consequences are:

Objects are kept alive that JavaScript cannot reach. A long that happens to have the bits of a heap address, sitting in a dead stack frame, keeps an entire object graph alive. This is the classic “my object never gets collected” mystery.
The scan is expensive. Every stack word is a candidate, and each candidate may require a page lookup and an object walk.
The scan is a security liability if you are not careful. A conservative scanner that accepts any value in a heap page as a pointer can be used to launder an attacker-controlled integer into a pointer.

V8 mitigates the last point by not always scanning the stack. There are three modes:

 cpp
 
 
// src/heap/heap.h:415
 StackScanMode ConservativeStackScanningModeForMajorGC() const {
 if (v8_flags.conservative_stack_scanning) {
 return StackScanMode::kFull;
 }
 if (selective_stack_scan_start_address_.has_value()) {
 DCHECK(IsGCWithStack());
 return StackScanMode::kSelective;
 }
 return StackScanMode::kNone;
 }

The mode enum is StackScanMode { kNone, kFull, kSelective }, declared a few lines above the function. kNone is the default: V8 does not scan the stack during a major GC unless it was asked to (--conservative-stack-scanning), or unless it is running with a stack (IsGCWithStack()), in which case it scans selectively from a recorded marker address upwards.

The remembered set: roots in the other direction

Precise root scanning finds the roots outside the heap. The remembered set is the mechanism that finds roots inside the old generation that point at the young generation.

The idea is the classic generational one. A scavenger only evacuates the young generation, so it must find every old object that points into it. The naive approach - scan the whole old generation - defeats the purpose of having a generational collector. So instead, the write barrier records the slots where an old object gets a young pointer:

 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));
 }
}

Two details are worth noting. The barrier records the slot in the old object, not the young object - so the remembered set is a set of slots to re-scan, and it stays small because old-to-new references are rare. And there are two separate slot sets, one for the main thread and one for background threads, because the main thread’s set is not thread-safe and the background’s is - V8 does not want the main thread to pay for atomic insertions.

The slot set itself is a per-page bit array of buckets:

 cpp
 
 
// src/heap/remembered-set.h:89
template <RememberedSetType type>
class RememberedSet : public AllStatic {
 public:
 // Given a page and a slot in that page, this function adds the slot to the
 // remembered set.
 template <AccessMode access_mode>
 static void Insert(MutablePage* page, size_t slot_offset) {
 SlotSet* slot_set = page->slot_set<type, access_mode>();
 if (slot_set == nullptr) {
 slot_set = page->AllocateSlotSet(type);
 }
 RememberedSetOperations::Insert<access_mode>(slot_set, slot_offset);
 }

The set is per page, so it is destroyed with the page and never has to be compacted. The cost of an old-to-new store is one bit-set in a small per-page array.

Ephemerons: WeakMap is not just “weak”

A WeakMap entry is not an ordinary weak reference. The value must be kept alive if and only if the key is alive. That is the ephemeron rule, and it is what makes WeakMap useful for memoisation: the value is only reachable through the map, so caching a value in a WeakMap keyed by an object does not keep the object alive.

V8 stores WeakMaps as EphemeronHashTables, and the marking visitor handles them specially:

 cpp
 
 
// src/heap/marking-visitor-inl.h:699
size_t MarkingVisitorBase<ConcreteVisitor>::VisitEphemeronHashTable(
 Tagged<Map> map, Tagged<EphemeronHashTable> table, MaybeObjectSize) {
 local_weak_objects_->ephemeron_hash_tables_local.Push(table);
 const bool use_key_to_values = key_to_values_ != nullptr;

 for (InternalIndex i : table->IterateEntries()) {
 ObjectSlot key_slot =
 table->RawFieldOfElementAt(EphemeronHashTable::EntryToIndex(i));
 Tagged<HeapObject> key = Cast<HeapObject>(table->KeyAt(i, kRelaxedLoad));

and the decision:

 cpp
 
 
// src/heap/marking-visitor-inl.h:721
 if (MarkingHelper::IsMarkedOrAlwaysLive(
 heap_, concrete_visitor()->marking_state(), key)) {
 VisitPointer(table, value_slot);
 } else {
 Tagged<Object> value_obj = table->ValueAt(i);

 if (IsHeapObject(value_obj)) {
 Tagged<HeapObject> value = Cast<HeapObject>(value_obj);
 SynchronizePageAccess(value);
 concrete_visitor()->RecordSlot(table, value_slot, value);

If the key is already marked, the value is marked too - a normal strong edge, taken right now. If the key is not yet marked, the pair is pushed onto the “next ephemerons” list to be reconsidered later.

That creates a fixpoint problem. Marking the value can mark other objects, which can mark other keys, which can make more values live. V8 solves it by iterating until nothing changes:

 cpp
 
 
// src/heap/mark-compact.cc:2141
bool MarkCompactCollector::MarkTransitiveClosureFixpoint() {
 int iterations = 0;

 auto process_ephemerons_to_fixpoint = [this, &iterations]() {
 bool another_ephemeron_iteration_main_thread;

 do {
 if (iterations >= v8_flags.ephemeron_fixpoint_iterations) {
 return false;
 }

with a bounded number of iterations. If the fixpoint is not reached within the budget, V8 falls back to a completely different, linear-time algorithm that builds a key -> values map instead of iterating:

 cpp
 
 
// src/heap/mark-compact.cc:2248
void MarkCompactCollector::MarkTransitiveClosureLinear() {
 TRACE_GC(heap_->tracer(),
 GCTracer::Scope::MC_MARK_WEAK_CLOSURE_EPHEMERON_LINEAR);
 // This phase doesn't support parallel marking.

The two algorithms are equivalent in outcome but very different in cost. The fixpoint algorithm can take many iterations; the linear one is O(entries) but cannot be parallelised.

The ephemeron remembered set

There is a subtlety that trips up almost everyone: an old-space EphemeronHashTable whose key is in the young generation does not appear in the ordinary old-to-new remembered set, because the ordinary set records slots that point at young objects - and here the value may be old while the key is young.

V8 keeps a second, dedicated structure for exactly this case:

 cpp
 
 
// src/heap/ephemeron-remembered-set.cc:12
void EphemeronRememberedSet::RecordEphemeronKeyWrite(
 Tagged<EphemeronHashTable> table, Address slot) {
 DCHECK(HeapLayout::InYoungGeneration(HeapObjectSlot(slot).ToHeapObject()));
 int slot_index = EphemeronHashTable::SlotToIndex(table.address(), slot);
 InternalIndex entry = EphemeronHashTable::IndexToEntry(slot_index);
 base::MutexGuard guard(&insertion_mutex_);
 auto it = tables_.insert({table, IndicesSet()});
 it.first->second.insert(entry.as_int());
}

The header explains the lifecycle:

 cpp
 
 
// src/heap/ephemeron-remembered-set.h:17
// Stores ephemeron entries where the EphemeronHashTable is in old-space,
// and the key of the entry is in new-space. Such keys do not appear in the
// usual OLD_TO_NEW remembered set. The remembered set is used to avoid
// strongifying keys in such hash tables in young generation garbage
// collections.
// This remembered set is exclusively used for Minor GCs. Once we start
// incremental marking for a Full GC this remembered set is cleared. The markers
// and write barriers for the Full GC will record these slots in the regular
// OLD_TO_NEW remembered set then. In addition after a Full GC new space is
// empty because all live objects were promoted, so we have the guaranteee that
// there are no old-to-new refs anymore.

So the ephemeron remembered set is a temporary structure, valid only for minor GCs, and it is cleared the moment a major GC starts.

WeakRef and FinalizationRegistry

WeakRef and FinalizationRegistry are implemented on top of the same machinery, but with an important twist: they need to notify JavaScript when a target dies, which means the GC has to run a callback.

MarkCompactCollector::ProcessJSWeakRefs does that work in a parallel job:

 cpp
 
 
// src/heap/mark-compact.cc:4239
void MarkCompactCollector::ProcessJSWeakRefs(JobDelegate* delegate) {
 Tagged<JSWeakRef> weak_ref;
 Isolate* const isolate = heap_->isolate();
 while (local_weak_objects()->js_weak_refs_local.Pop(&weak_ref)) {
 Tagged<HeapObject> target = Cast<HeapObject>(weak_ref->target());
 if (MarkingHelper::IsUnmarkedAndNotAlwaysLive(
 heap_, non_atomic_marking_state_, target)) {
 weak_ref->set_target(ReadOnlyRoots(isolate).undefined_value(),
 SKIP_WRITE_BARRIER);
 } else {
 // The value of the JSWeakRef is alive.
 ObjectSlot slot(&weak_ref->target_);
 RecordSlot(weak_ref, slot, target);
 }
 }

A WeakRef whose target died is reset to undefined, and the FinalizationRegistry holding a WeakCell for that target is put on the dirty list so its cleanup callback runs later, outside the GC pause.

The weak lists

Some root structures are weak - they are on a singly linked list where the “next” pointer is weak, so dead elements can be unlinked. V8 has a generic machinery for this:

 cpp
 
 
// src/heap/heap-visitor.cc:21
template <class T>
Tagged<Object> VisitWeakList(Heap* heap, Tagged<Object> list,
 WeakObjectRetainer* retainer) {
 static constexpr int kSlotOffset = WeakListVisitor<T>::kWeakNextOffset;

 Tagged<HeapObject> undefined = ReadOnlyRoots(heap).undefined_value();
 Tagged<Object> head = undefined;
 Tagged<T> tail;
 const bool should_record_slots = retainer->ShouldRecordSlots();

 while (list != undefined) {
 // Check whether to keep the candidate in the list.
 Tagged<Object> retained = retainer->RetainAs(list);

 // Move to the next element before the WeakNext is cleared.
 list = Cast<HeapObject>(list)->RawField(kSlotOffset).load();

The Context list, the AllocationSite list and the JSFinalizationRegistry list are all weak lists, and each has its own specialisation of WeakListVisitor for what “visiting a live object” means in that context.

Trade-offs

What it buys. A precise root set means the GC can move objects (compaction) and can know exactly which references need updating. A conservative root set would force the collector to treat the whole stack as a root set and give up on moving anything the stack might point at.

What it costs.

The root set is a fixed list, and every entry costs. Every handle scope block, every global handle node, every traced handle, every roots table entry is scanned on every GC. For an application with a million global handles, that is a million nodes walked.
Conservative scanning is a heuristic with false positives. An integer on the stack that looks like a pointer keeps an object alive. V8’s answer is to not scan the stack at all by default.
The remembered set is a side effect of the write barrier. Every old-to-new store costs a slot-set insertion. This is the price of not scanning the whole old generation during a scavenger.
Ephemerons need a fixpoint. WeakMap semantics cannot be resolved in a single pass, so the marking phase may need several iterations, and the fallback algorithm is single-threaded.
Weak callbacks run outside the pause. FinalizationRegistry cleanup is scheduled as a task, which means it runs at a point where the application is not expecting it.

The bottom line

Root scanning is the part of a garbage collector that is easiest to get subtly wrong, because “root” is not one thing. V8 splits it into a precise half (the roots table, handle scopes, global handles, traced handles, the embedder’s registered strong roots) and a conservative half (the machine stack), and the two have completely different failure modes: the precise half misses nothing but is expensive, the conservative half is cheap to set up but keeps garbage alive.

Then there is the remembered set, which is the same idea turned inside out: instead of finding roots outside the heap, it records the slots inside the old generation that point into the young one, so that the scavenger can treat those slots as roots. That is why V8 can have a generational collector and a precise one.

And the ephemerons are the third axis: WeakMap is not a weak reference, it is a conditional strong reference, and implementing it correctly is what forces the marking phase to iterate to a fixpoint.

The thing people get wrong

“JavaScript objects are garbage collected when nothing references them” is false in two specific ways that both show up in practice.

The first is the conservative stack scan. If V8 is scanning the stack, an object can be kept alive by a stale integer in a dead stack frame. The mitigation is not “fix your code” but “do not enable --conservative-stack-scanning” - which is why it is off by default.

The second is WeakMap. new WeakMap().set(key, value) does not keep key alive - that is the point - but the value is kept alive exactly as long as the key is, and the key is kept alive exactly as long as something else references it. If your WeakMap looks like it is retaining values forever, the key is being retained by something else - often by a closure that captured it.

The third and most common: a FinalizationRegistry callback does not run at a predictable time. It runs after the target has been determined dead, which is at least one GC later, and only if the isolate is still alive and the callback does not allocate. If you need deterministic cleanup, use try/finally or an explicit dispose method - not a finalizer.

Handles on Opensource internals