Name Description Size Coverage
Allocator-inl.h Inline definitions of the CellAllocator methods. This is included from JSContext-inl.h for the definiton of JSContext::newCell and shouldn't need to be included elsewhere. 9256 95 %
Allocator.cpp static 23288 98 %
Allocator.h 7762 95 %
AllocKind.h GC-internal definition of GC cell kinds. 15337 87 %
ArenaList-inl.h 8044 82 %
ArenaList.h GC-internal definitions of ArenaList and associated heap data structures. 12314 94 %
AtomMarking-inl.h static 5054 96 %
AtomMarking.cpp 18608 94 %
AtomMarking.h 5178 100 %
Barrier.cpp 4532 59 %
Barrier.h 46317 90 %
BufferAllocator-inl.h static 4340 90 %
BufferAllocator.cpp 116619 88 %
BufferAllocator.h 28641 100 %
BufferAllocatorInternals.h 16407 99 %
Cell.h namespace JS 29429 99 %
ClearEdgesTracer.h 770 -
Compacting.cpp Implementation of compacting GC. 33184 99 %
FinalizationObservers.cpp GC support for FinalizationRegistry and WeakRef objects. 17033 97 %
FinalizationObservers.h 7400 92 %
FindSCCs.h 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. node2.gcGraphEdges.put(node3); node3.gcGraphEdges.put(node2); ComponentFinder<MyGraphNode> finder; finder.addNode(node1); finder.addNode(node2); finder.addNode(node3); MyGraphNode* result = finder.getResultsList(); 5278 97 %
GC-inl.h 11770 99 %
GC.cpp 184829 88 %
GC.h JS engine garbage collector API. 12871 100 %
GCAPI.cpp API functions and methods used by the rest of SpiderMonkey and by embeddings. 24522 82 %
GCArray.h A fixed size array of |T| for use with GC things. Must be allocated manually to allow space for the trailing elements data. Call bytesRequired to get the required allocation size. Does not provide any barriers by default. 3284 100 %
GCContext-inl.h 1243 100 %
GCContext.h 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. 7990 100 %
GCEnum.h GC-internal enum definitions. 6001 -
GCInternals.h GC-internal definitions. 9817 100 %
GCLock.h GC-internal classes for acquiring and releasing the GC lock. 2673 100 %
GCMarker.h 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). 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. 23963 100 %
GCParallelTask.cpp 7700 95 %
GCParallelTask.h ArgTs 8364 96 %
GCProbes.h 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. 1288 100 %
GCRuntime.h 56429 92 %
GenerateStatsPhases.py 12670 -
HashUtil.h 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(). 2520 93 %
Heap-inl.h 7787 97 %
Heap.cpp Tenured heap management. This file contains method definitions for the following classes for code that is not specific to a particular phase of GC: - Arena - ArenaList - FreeLists - ArenaLists - ArenaChunk - ChunkPool 21658 86 %
Heap.h A FreeSpan represents a contiguous sequence of free cells in an Arena. It can take two forms. - In an empty span, |first| and |last| are both zero. - In a non-empty span, |first| is the address of the first free thing in the span, and |last| is the address of the last free thing in the span. Furthermore, the memory pointed to by |last| holds a FreeSpan structure that points to the next span (which may be empty); this works because sizeof(FreeSpan) is less than the smallest thingSize. 23070 76 %
IteratorUtils.h 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. 2608 98 %
Marking-inl.h static 8044 92 %
Marking.cpp clang-format off 105802 83 %
Marking.h Marking and sweeping APIs for use by implementations of different GC cell kinds. 4657 100 %
MaybeRooted.h 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. 3679 100 %
Memory.cpp System allocation functions generally require the allocation size to be an integer multiple of the page size of the running process. 40257 61 %
Memory.h gc_Memory_h 4358 -
moz.build 1793 -
Nursery-inl.h safe - used for value in comparison above 13573 82 %
Nursery.cpp 81861 82 %
Nursery.h Key Header text 28154 99 %
NurseryAwareHashMap.h 8230 93 %
ObjectKind-inl.h GC-internal helper functions for getting the AllocKind used to allocate a JSObject and related information. 6369 97 %
ParallelMarking.cpp static 10523 95 %
ParallelMarking.h gc_ParallelMarking_h 4445 86 %
ParallelWork.h namespace gc 3897 98 %
Policy.h JS Garbage Collector. 3715 52 %
Pretenuring.cpp static 21161 52 %
Pretenuring.h Pretenuring. 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. 15751 95 %
PrivateIterators-inl.h GC-internal iterators for various data structures. 4268 92 %
PublicIterators.cpp 9347 70 %
PublicIterators.h Iterators for various data structures. 4183 100 %
RelocationOverlay.h GC-internal definition of relocation overlay used while moving cells. 1676 100 %
RootMarking.cpp 15373 93 %
Scheduling.cpp 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. 30710 82 %
Scheduling.h 44076 95 %
StableCellHasher-inl.h static 6789 82 %
StableCellHasher.h 1414 -
Statistics.cpp 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. 58823 59 %
Statistics.h Number of zones collected in this GC. 18730 96 %
StoreBuffer-inl.h static 3006 100 %
StoreBuffer.cpp 12540 95 %
StoreBuffer.h 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. 21408 92 %
Sweeping.cpp 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. 87912 93 %
Tenuring.cpp Implementation of nursery eviction (tenuring). 57516 93 %
Tenuring.h 5565 100 %
TraceKind.h namespace gc 1782 100 %
TraceMethods-inl.h Trace methods for all GC things, defined in a separate header to allow inlining. This also includes eager inline marking versions. Both paths must end up traversing equivalent subgraphs. 14528 96 %
Tracer.cpp Public Tracing API **************************************************** 8263 94 %
Tracer.h 17201 96 %
Verifier.cpp 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. Pre-Barrier Verifier: 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 verification phase. 36937 0 %
WeakMap-inl.h static 27411 98 %
WeakMap.cpp static 10378 84 %
WeakMap.h 19650 98 %
WeakMapPtr.cpp 2995 98 %
Zone.cpp 27960 87 %
Zone.h 36034 97 %
ZoneAllocator.h Public header for allocating memory associated with GC things. 14063 87 %