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. 9141 95 %
Allocator.cpp static 23548 -
Allocator.h 7585 95 %
AllocKind.h GC-internal definition of GC cell kinds. 15221 87 %
ArenaList-inl.h 7929 82 %
ArenaList.h GC-internal definitions of ArenaList and associated heap data structures. 12199 94 %
AtomMarking-inl.h static 5189 96 %
AtomMarking.cpp 18468 -
AtomMarking.h 5064 100 %
Barrier.cpp 4417 -
Barrier.h 50339 88 %
BufferAllocator-inl.h static 4147 90 %
BufferAllocator.cpp 121053 -
BufferAllocator.h 29137 100 %
BufferAllocatorInternals.h 17481 99 %
Cell.h namespace JS 32024 99 %
ChunkPool.h namespace gc 1986 100 %
ClearEdgesTracer.h 655 -
Compacting.cpp Implementation of compacting GC. 32153 -
FinalizationObservers.cpp GC support for FinalizationRegistry and WeakRef objects. 24438 -
FinalizationObservers.h 8216 96 %
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(); 5169 97 %
GC-inl.h 12521 99 %
GC.cpp 190339 -
GC.h JS engine garbage collector API. 12815 100 %
GCAPI.cpp API functions and methods used by the rest of SpiderMonkey and by embeddings. 24581 -
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. 3169 100 %
GCContext-inl.h 1128 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. 7907 97 %
GCEnum.h GC-internal enum definitions. 6071 -
GCInternals.h GC-internal definitions. 9702 100 %
GCLock.h GC-internal classes for acquiring and releasing the GC lock. 2558 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. 25972 97 %
GCParallelTask.cpp 7608 -
GCParallelTask.h ArgTs 8249 88 %
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. 1173 100 %
GCRuntime.h 58318 91 %
GenerateStatsPhases.py 12790 -
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(). 2405 93 %
Heap-inl.h 7501 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 21809 -
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. 22758 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. 2493 100 %
LightLock.cpp static 3452 -
LightLock.h 3615 0 %
Marking-inl.h static 7892 92 %
Marking.cpp clang-format off 115384 -
Marking.h Marking and sweeping APIs for use by implementations of different GC cell kinds. 4479 85 %
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. 3564 100 %
Memory.cpp System allocation functions generally require the allocation size to be an integer multiple of the page size of the running process. 40515 63 %
Memory.h gc_Memory_h 4243 -
moz.build 1725 -
Nursery-inl.h safe - used for value in comparison above 13457 88 %
Nursery.cpp 81973 -
Nursery.h Key Header text 27648 99 %
NurseryAwareHashMap.h 7245 98 %
ObjectKind-inl.h GC-internal helper functions for getting the AllocKind used to allocate a JSObject and related information. 6254 97 %
ParallelMarking.cpp static 12249 -
ParallelMarking.h gc_ParallelMarking_h 5000 86 %
ParallelWork.h namespace gc 4318 98 %
Policy.h JS Garbage Collector. 3122 81 %
Pretenuring.cpp static 21128 -
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. 15524 95 %
PrivateIterators-inl.h GC-internal iterators for various data structures. 4153 92 %
PublicIterators.cpp 9172 -
PublicIterators.h Iterators for various data structures. 4241 100 %
RelocationOverlay.h GC-internal definition of relocation overlay used while moving cells. 1561 100 %
RootMarking.cpp 14894 -
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. 30631 -
Scheduling.h 43958 95 %
StableCellHasher-inl.h static 5918 80 %
StableCellHasher.h 1180 -
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. 58913 -
Statistics.h Number of zones collected in this GC. 18615 96 %
StoreBuffer-inl.h static 2848 98 %
StoreBuffer.cpp 12290 94 %
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. 21272 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. 90378 -
Tenuring.cpp Implementation of nursery eviction (tenuring). 58591 -
Tenuring.h 5704 100 %
TraceKind.h namespace gc 1667 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. 15185 96 %
Tracer.cpp Public Tracing API **************************************************** 9004 -
Tracer.h 15799 97 %
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. 38841 -
WeakMap-inl.h static 27926 98 %
WeakMap.cpp 10419 -
WeakMap.h 20420 98 %
WeakMapPtr.cpp 2880 -
Zone.cpp 28053 -
Zone.h 38366 98 %
ZoneAllocator.h Public header for allocating memory associated with GC things. 13879 87 %