||GC-internal definition of GC cell kinds.
||GC-internal definitions of ArenaList and associated heap data structures.
||Implementation of compacting GC.
||GC support for FinalizationRegistry and WeakRef objects.
||Find the strongly connected components of a graph using Tarjan's algorithm,
and return them in topological order.
Nodes derive from GraphNodeBase and add target edge pointers to
sourceNode.gcGraphEdges to describe the graph:
struct MyGraphNode : public GraphNodeBase<MyGraphNode>
MyGraphNode node1, node2, node3;
node1.gcGraphEdges.put(node2); // Error checking elided.
MyGraphNode* result = finder.getResultsList();
||JS engine garbage collector API.
||API functions and methods used by the rest of SpiderMonkey and by embeddings.
||GCContext is by GC operations that can run on or off the main thread.
Its main function is to provide methods to free memory and update memory
accounting. For convenience, it also has delete_ convenience methods that
also call destructors.
It is passed to finalizers and other sweep-phase hooks as JSContext is not
available off the main thread.
||GC-internal enum definitions.
||GC-internal classes for acquiring and releasing the GC lock.
||The mark stack. Pointers in this stack are "gray" in the GC sense, but
their references may be marked either black or gray (in the CC sense)
depending on whether they are above or below grayPosition_.
When the mark stack is full, the GC does not call js::TraceChildren to mark
the reachable "children" of the thing. Rather the thing is put aside and
js::TraceChildren is called later when the mark stack is empty.
To implement such delayed marking of the children with minimal overhead for
the normal case of sufficient stack, we link arenas into a list using
Arena::setNextDelayedMarkingArena(). The head of the list is stored in
GCMarker::delayedMarkingList. GCMarker::delayMarkingChildren() adds arenas
to the list as necessary while markAllDelayedChildren() pops the arenas from
the stack until it is empty.
||This interface can be used to insert probes for GC related events.
The code must be built with JS_GC_PROBES for these probes to be called
from JIT code.
||Used to add entries to a js::HashMap or HashSet where the key depends on a GC
thing that may be moved by generational or compacting GC between the call to
lookupForAdd() and relookupOrAdd().
||Tenured heap management.
This file contains method definitions for the following classes for code that
is not specific to a particular phase of GC:
||The minimum cell size ends up as twice the cell alignment because the mark
bitmap contains one bit per CellBytesPerMarkBit bytes (which is equal to
CellAlignBytes) and we need two mark bits per cell.
||Create an iterator that yields the values from IteratorB(a) for all a in
IteratorA(). Equivalent to nested for loops over IteratorA and IteratorB
where IteratorB is constructed with a value from IteratorA.
||Marking and sweeping APIs for use by implementations of different GC cell
||Template types for use in generic code: to use Rooted/Handle/MutableHandle in
cases where GC may occur, or to use mock versions of those types that perform
no rooting or root list manipulation when GC cannot occur.
||System allocation functions generally require the allocation size
to be an integer multiple of the page size of the running process.
||safe - used for value in comparison above
||Key Header text
||GC-internal helper functions for getting the AllocKind used to allocate a
JSObject and related information.
||JS Garbage Collector.
Some kinds of GC cells can be allocated in either the nursery or the tenured
heap. The pretenuring system decides where to allocate such cells based on
their expected lifetime with the aim of minimising total collection time.
Lifetime is predicted based on data gathered about the cells' allocation
site. This data is gathered in the middle JIT tiers, after code has stopped
executing in the interpreter and before we generate fully optimized code.
||GC-internal iterators for various data structures.
||Iterators for various data structures.
||GC-internal definition of relocation overlay used while moving cells.
||We may start to collect a zone before its trigger threshold is reached if
GCRuntime::maybeGC() is called for that zone or we start collecting other
zones. These eager threshold factors are not configurable.
||If this fails, then you can either delete this assertion and allow all
larger-numbered reasons to pile up in the last telemetry bucket, or switch
to GC_REASON_3 and bump the max value.
||Number of zones collected in this GC.
||BufferableRef represents an abstract reference for use in the generational
GC's remembered set. Entries in the store buffer that cannot be represented
with the simple pointer-to-a-pointer scheme must derive from this class and
use the generic store buffer interface.
A single BufferableRef entry in the generic buffer can represent many entries
in the remembered set. For example js::OrderedHashTableRef represents all
the incoming edges corresponding to keys in an ordered hash table.
||Implementation of GC sweeping.
In the SpiderMonkey GC, 'sweeping' is used to mean two things:
- updating data structures to remove pointers to dead GC things and updating
pointers to moved GC things
- finalizing dead GC things
Furthermore, the GC carries out gray and weak marking after the start of the
sweep phase. This is also implemented in this file.
||Implementation of nursery eviction (tenuring).
||Trace methods for all GC things, defined in a separate header to allow
This also includes eager inline marking versions. Both paths must end up
traversing equivalent subgraphs.
||Public Tracing API ****************************************************
||Write barrier verification
The next few functions are for write barrier verification.
The VerifyBarriers function is a shorthand. It checks if a verification phase
is currently running. If not, it starts one. Otherwise, it ends the current
phase and starts a new one.
The user can adjust the frequency of verifications, which causes
VerifyBarriers to be a no-op all but one out of N calls. However, if the
|always| parameter is true, it starts a new phase no matter what.
When StartVerifyBarriers is called, a snapshot is taken of all objects in
the GC heap and saved in an explicit graph data structure. Later,
EndVerifyBarriers traverses the heap again. Any pointer values that were in
the snapshot and are no longer found must be marked; otherwise an assertion
triggers. Note that we must not GC in between starting and finishing a
||Public header for allocating memory associated with GC things.