This is the third article in a series.
memory structure
The memory space allocated by a running program in V8 is called a Resident Set.
The stack holds statically allocated data, the frame function, the Primitive variable, and Pointers to object variables. The bottom of the stack is the Global frame, which holds the global data and is always present during the execution of the program. The rest is the execution context stack. The top is the executing context. Memory management for this area is controlled by the OS.
The heap area holds dynamically allocated data, and memory management is controlled by V8, so this is where GC happens later. Young Generation will be discussed in depth in the next section. Old generation is divided into Map space and Old object space. Map space only contains map objects, namely the Shape mentioned above, while the rest contains old objects. Large object space stores objects that exceed a certain size limit. Larget objects will be created in large object space and released timely without being moved. Code space is a place where the compiler stores compiled code blocks, which may intersect with large object Spaces and are not represented in the figure.
gc
There are two garbage collectors in V8. The first is the Major (Mark-Compact) GC, which collects garbage from the entire heap, and the second is the Minor (Scavenger) GC, which collects garbage from only the young generation.
Mark-Compact
Gc here includes marking, sweeping and compacting three stages.
- Marking
The GC starts with a list of known Pointers to objects called root sets, including the Execution stack and the Global object, and then recursively queries along each pointer and marks the traversed object as reachable, The value is reserved for the time being
- Sweeping
The gc treats the unmarked objects as dead objects and adds them to a data structure called free-list that can be used to allocate memory in the future.
- Compaction
Surviving Objects are copied to the current non-compacted area so that the small and scattered memory of dead objects can be utilized. However, if there are many surviving objects, this replication is very performance consuming and therefore only very fragmented fragments will be processed.
Scavenger
The heap is divided into young generation and an old generation. Scavenger occurs in the young generation. The young generation is divided into two halves of space, half of which is always empty. The empty half is called to-space and the other half is called from-space. After a GC, reachable objects are copied From from-space To to-space. Now the two Spaces are interchangeable. According to The Generational Hypothesis, that is, after most objects are allocated, they immediately become unreachable and only a few objects need to be replicated.
If this continues, the young generation will fill up quickly, so the young generation can be subdivided into two children: Objects are first allocated to the nursery, moved to intermediate if they exist after the next GC, and moved to old Generation if they exist again
Orinoco
Orinoco is the code name for the V8 garbage collector project and includes the following technologies
- Parallel
Both the main and helper threads are processed at the same time, blocking the main thread, which is how the two garbage collections described above are being used
- Incremental
Incremental processing to reduce the time the main thread blocks. Changes in heap state can invalidate some incremental processing.
- Concurrent
The main thread does not block, only the helper thread garbage collection. In addition to the former problem, the main thread and the helper thread have to deal with read and write contention and information synchronization between the helper threads.
Idle-time GC
In addition to V8’s own GC, a mechanism is provided to trigger garbage collection for embedders (such as browsers) : V8 will publish idle tasks that can be triggered by browsers whenever a frame is idle.
This can also be considered the third GC offered by V8.
reference
- chromium.googlesource.com
- Trash talk: the Orinoco garbage collector
- Visualizing memory management in V8 Engine
- Understanding Garbage Collection and hunting Memory Leaks in Node.js