Welcome back. From the previous lectures 1
we know the concept of the GC pauses, that is, the state where the Mutator is completely blocked, not 2
doing any useful work, while the Collector takes place. 3
The state is also known as "Stop-the-World". 4
In today's lecture we'll see, how this can be improved, and we'll talk about Parallel, Incremental, and 5
Concurrent garbage collection. 6
First, let's actually recall the Stop-the-World state, and see what happens with the user program that is 7
Mutator 8
when the Garbage Collector takes place. As we can see, Mutator is completely blocked until the Collector 9
finished its work. Usually simple Stop-the-World 10
collectors have only one collection thread, and while it might seem not very performant 11
implementing a single-threaded blocking collector is very simple 12
and that's why it's still widely used in practice. 13
Collector finished its work, Mutator can proceed 14
Again: GC pause, Collector works, completes 15
then again Mutator can proceed. 16
And 17
as we said previously, not every system can actually tolerate such GC pauses. 18
For example, hardware drivers, transaction processing, etc. So, modern production collectors constantly 19
investigate how to reduce these GC pauses, and improve GC performance. 20
One of the approaches to increase the speed of the GC, is Parallel collectors. With the Parallel collectors 21
there is sometimes confusion among developers. 22
It might seem from the name, that a Parallel collector runs in parallel with Mutator. 23
However, a Parallel collector is still a blocking Stop-the-World collector. 24
The difference though, is that the collector itself uses several threads for its purposes. 25
This usually relates to the heap partition, and assigning a region of a heap per collector thread. 26
For example, we have some objects on the heap, and then one collector thread is assigned to this region 27
another one handles this part, and this thread works with other objects. 28
When implementing a parallel collector one should be careful with threads synchronization. 29
For example, for parallel copying each threads should cooperate to avoid double copies or overwrite already 30
copied object by some other thread. 31
Also not every data structure can be handled in parallel. Sometimes like in linked lists 32
each element should be marked one after another 33
and using a Parallel collector doesn't bring much performance improvements. 34
Other data structures like trees might better fit for parallel processing. 35
Another important thing of a Parallel collector, is to have a good load balancer. For example, when one 36
thread finished its work, it can borrow some work from another thread. 37
If a balancer is implemented poorly, a Parallel collector can even slow down the cycle. 38
So, one thing to remember again, is that the Parallel collector is still a 39
Stop-the-World collector, but uses several threads for its own work. 40
Another technique to reduce GC pauses are the Incremental collectors. 41
And even though they reduced the actual GC pauses, Incremental collectors are also actually Stop-the-World 42
collectors 43
That is, the new Mutator is also completely blocked, while the Collector takes place. 44
The difference here though, is that the Collector can be interrupted by the Mutator before completion. 45
Right 46
So, for example, a Collector finished marking, but hasn't finished yet the actual collection. 47
This brings some synchronization issues between collector and Mutator. 48
Imagine that during the Marking phase the Collector didn't mark some object, that is is potentially identified 49
as a garbage. 50
Then the Mutator interrupts the Collector 51
that is, before the collector finished its Sweep phase. And then the object actually receives an alive 52
reference, that is, it is not a garbage anymore. 53
Then again stars the Collector, which now should complete its cycle, and reclaimed the garbage, which was 54
identified on the previous Marking phase. From the Mutator's perspective 55
this object is not a garbage anymore, and if the Collector removes it, it breaks heap invariants by 56
reclaiming an alive object. 57
So, the Collector somehow should be notified that this object is now alive. 58
That is, when the Collector continues its cycle 59
this object should be marked alive for it, and not reclaimed. Running forward, we should say that this 60
synchronization process is known as Read and Write barriers -- similar to the Write barrier which 61
we have been discussing in the Generation collectors topic. 62
But we'll be talking about GC barriers in detail and with examples in the next lectures when we'll be 63
discussing Tri-color abstraction. And in case of the Incremental collector 64
this is one GC pause, that is, to reiterate, the collector was interrupted and continued after portion 65
of a time of the Mutator. 66
Now let's see 67
even more advanced collector known as Concurrent. This collector type in contrasts with all discussed 68
previously 69
actually runs some of its phases concurrently with Mutator. That is, Mutator is not blocked while the 70
Collector, for example, marks of the objects. What is interesting, the synchronization issues and techniques 71
here pretty much the same as an Incremental collector. And the same to identify some object as alive. 72
this collector needs synchronization barriers, which again will be discussed in the next lectures. 73
We should also say that usually a Concurrent collector can run concurrently 74
only some of the phases. At some point it still needs to enforce Stop-the-World state to correctly finish 75
the cycle. 76
So, usually such collectors are actually called "Almost Concurrent" collectors. 77
Okay. 78
Here is the summary for today's lecture. 79
Let's take a look. 80
As we said, despite being called Parallel, this collector type is actually the same Stop-the-World. 81
It just exploits several collection threads, partitioning the heap. The Incremental and Concurrent collectors 82
both can be interrupted by the Mutator, and before the completion or even run in parallel. 83
And for both collector types will need to have synchronization barriers. 84
The obvious advantage of this collector types is reducing the GC pauses, since Mutator is less blocked 85
and even can continue its work while the Collector identifies the garbage. The allocation mechanism 86
in general doesn't depend on whether we collect in parallel 87
except of course synchronization mechanisms. And allowing Mutator to run in parallel or incrementally 88
this collector type brings an overhead in the view of the Read and Write barriers, when pointer operations 89
have to be trapped. 90
Okay. 91
In the next lecture we'll talk about Tri-color abstraction, and to see how it's used in Concurrent and 92
Incremental collectors 93
when implemented GC barriers. 94
Thanks and see you in the next lectures.