Welcome back. 1
In this video we're going to talk about different modules involved into a garbage collected program. 2
As we have mentioned earlier, the objects can be allocated on the heap. 3
That is the dynamic memory of a process. And recall also from the previous lecture that the requests 4
for the memory allocation are done through the mechanism of memory mapping. 5
And when we deal with a garbage collected program, we always consider it from the perspective of the 6
three main modules, known as the Mutator, Allocator and Collector. 7
So in this lecture we go in to discuss them in detail. 8
First we started with a Mutator. And the Mutator is our main program, that is the actual useful 9
code. 10
It operates on some heap-allocated objects, and Mutator's view of the object graph is canonical. 11
All the other modules should respect this canonical view of the Mutator. 12
However, it doesn't allocate the objects itself. 13
Instead it delegates this operation to another module known as the Allocator. 14
Now, they Allocator directly manipulates the heap. It allocates the memory of needed size 15
and also tracks the meta-information of the allocated objects. 16
This meta-information as we know from the previous lectures is called the Object header. The result 17
of the Allocator is a pointer to the allocated memory block. 18
And here we have our Collector. 19
That is, the Garbage Collector, and which also directly manipulates the heap. Collector as we said should 20
respect Mutator's view of the object graph in terms of preserving the heap invariants. For 21
example 22
under no circumstances the Collector can reclaim an alive object (otherwise it would be a very bad collector) 23
The Collector also closely communicates with the Allocator, for example, to synchronize on the Object header 24
structure. 25
In general the Mutator may not even know that the Collector exists. Usually in higher programming 26
languages from the user code 27
we don't deal directly with a garbage collector. 28
However, some languages expose API to call the garbage collector explicitly. 29
For example, the System.gc() call in Java, or gc.collect() in Python, etc.. 30
So these are the main three modules which communicate to each other during their lifecycle of a program. 31
And when we consider Mutator and Collector communication, there is a state of the Mutator 32
known as the "Stop the world". 33
Now, what it means is that all Mutator threads are completely blocked not doing any useful work, while 34
the Collector takes place. And ones the Collector has completed its work, Mutator can proceed. As 35
we can also see, the Collector itself may have several threads doing the collection work in parallel. 36
Collector is completed, the Mutator again may proceed. And such collection cycles when the Mutator 37
is completely blocked, are known as the GC pauses. And not every system can tolerate such pauses, for 38
example, real-time systems, hardware drivers, transaction processing, etc. In general a Stop-the-world algorithm 39
is of course easier to implement than the concurrent algorithm, and that's why it's still widely used 40
on practice in many implementations. However as we'll see further in this class modern production garbage 41
collectors involve incremental and concurrent approaches to reclaim the garbage, and what of course reduces 42
these GC pauses. 43
Okay now when we understand where the Collector fits into a program lifecycle and how it relates to 44
other modules 45
let's talk about two main collector types 46
the Tracing and the Direct collectors which will be discussing in the next video.