1
00:00:06,810 --> 00:00:07,260
Hello.

2
00:00:08,070 --> 00:00:15,270
In this video, we'll talk about Question eight, how does the garbage collector decide which objects

3
00:00:15,270 --> 00:00:17,160
can be removed from memory?

4
00:00:17,730 --> 00:00:24,720
As you hopefully know, the garbage collector is the common language runtime mechanism that is responsible

5
00:00:24,720 --> 00:00:27,580
for memory management in different applications.

6
00:00:27,990 --> 00:00:33,360
Its main role is to remove from the memory the objects that are no longer needed.

7
00:00:33,900 --> 00:00:41,580
The algorithm it implements is called mark sweep because first it marks objects that can be removed

8
00:00:41,670 --> 00:00:44,190
and the done sweeps them from memory.

9
00:00:44,580 --> 00:00:48,060
But how can we tell if an object can be removed?

10
00:00:48,630 --> 00:00:53,760
In simplest terms, when there are no existing references that point to this object?

11
00:00:54,060 --> 00:00:56,130
But how can the garbage collector know it?

12
00:00:56,310 --> 00:01:00,210
Well, in the family of tools similar to the garbage collector?

13
00:01:00,420 --> 00:01:03,990
And remember, this concept is not exclusive to dot net.

14
00:01:04,290 --> 00:01:07,020
There are two most commonly used algorithms.

15
00:01:07,410 --> 00:01:12,780
The first is called reference counting, which, for example, is used in swift.

16
00:01:13,320 --> 00:01:19,320
According to this algorithm, the garbage collector keeps track of the count of references pointing

17
00:01:19,320 --> 00:01:20,340
to some object.

18
00:01:20,580 --> 00:01:27,030
When the count, which is zero, it considers this object and referenced by another object and does

19
00:01:27,060 --> 00:01:29,550
a candidate to be removed from memory.

20
00:01:30,030 --> 00:01:32,400
There is a problem with this algorithm, though.

21
00:01:32,750 --> 00:01:35,700
Imagine there are two objects A and B.

22
00:01:36,210 --> 00:01:40,530
There is a reference from A to B and a reference from B to A.

23
00:01:40,800 --> 00:01:44,160
And such reference is called circular reference.

24
00:01:44,580 --> 00:01:53,220
But no other object in the application references A nor B, A and B objects could be removed from memory

25
00:01:53,400 --> 00:01:58,620
because they cannot be reached from any point in the application, but signs for both of them.

26
00:01:58,650 --> 00:02:01,290
The reference count is one, not zero.

27
00:02:01,590 --> 00:02:07,920
A garbage collector using the reference counting algorithm would not remove them because of DOT, a

28
00:02:07,920 --> 00:02:11,360
reference counting is not used in, not instead.

29
00:02:11,640 --> 00:02:13,020
Tracing is used.

30
00:02:13,530 --> 00:02:20,910
Tracing will determine whether an object is mutable or not by tracing it from a set of application routes.

31
00:02:21,300 --> 00:02:27,360
We will learn what application roots are in a minute, but for now, let's just say there are objects

32
00:02:27,360 --> 00:02:31,110
that the garbage collector starts building the graph of readability from.

33
00:02:31,620 --> 00:02:38,730
If an object is reachable from a root object, either directly or indirectly, then it will be considered

34
00:02:38,730 --> 00:02:39,330
alive.

35
00:02:39,570 --> 00:02:43,650
If it's not reachable, it means it can be removed from memory.

36
00:02:44,190 --> 00:02:48,840
Let's say that the garbage collector identifies pre-application application routes.

37
00:02:49,260 --> 00:02:52,170
They, by definition, are considered suitable.

38
00:02:52,590 --> 00:02:58,950
Then for each of them, the garbage collector chokes what references they hold, and it adds the objects

39
00:02:58,950 --> 00:03:03,060
punctured by those references to the graph of readable objects.

40
00:03:03,540 --> 00:03:06,930
It repeats this step for each of the new objects.

41
00:03:07,290 --> 00:03:13,980
It continues its work until there are no more objects having references to objects that are not included

42
00:03:13,980 --> 00:03:14,640
in the graph.

43
00:03:15,240 --> 00:03:21,620
The power of this algorithm is that the circular references will not be included in the graph of heritable

44
00:03:21,630 --> 00:03:24,720
objects because, well, they are not reachable.

45
00:03:25,440 --> 00:03:29,790
All right, let's now see what application routes are exactly.

46
00:03:30,090 --> 00:03:36,570
Routes includes static fields and local variables on the tract stuck to be more specific.

47
00:03:36,600 --> 00:03:41,940
There are also a couple more things that will be included in the Application Roots collection, but

48
00:03:41,940 --> 00:03:46,920
they come from a low level mechanism of C-sharp, which are beyond this conscious scope.

49
00:03:47,310 --> 00:03:52,170
If you are curious, I linked a document about that intellectual resources.

50
00:03:52,590 --> 00:03:57,660
For us, the most important part is local variables on the threat stack.

51
00:03:58,260 --> 00:04:05,220
First thing we need to clarify each thread has its own stock, so in multi-threaded applications, we

52
00:04:05,220 --> 00:04:08,400
will have more than one stack for simplicity.

53
00:04:08,580 --> 00:04:11,130
Let's focus on single threaded applications.

54
00:04:11,430 --> 00:04:17,550
The garbage collector will look at the stack and see what references are currently stored on it.

55
00:04:18,030 --> 00:04:24,990
Remember, the reference itself is stored on the stock and it points to an object stored on the heap.

56
00:04:25,380 --> 00:04:30,330
Let's consider this code execution point marked by the arrow.

57
00:04:30,450 --> 00:04:33,330
The following references are stored on the stock.

58
00:04:33,900 --> 00:04:37,740
The reference to the person object stored in the person variable.

59
00:04:38,280 --> 00:04:46,440
The reference to the BBB string stored in the text variable and deformed references are not stored on

60
00:04:46,440 --> 00:04:47,040
the stock.

61
00:04:47,550 --> 00:04:54,990
The reference to the tongue string it is stored in the person object and the reference to the string

62
00:04:54,990 --> 00:04:57,060
stored in the text inside.

63
00:04:57,060 --> 00:05:01,410
If variable, it's not on the stock because it was removed from it.

64
00:05:01,530 --> 00:05:02,480
Once Decode X.

65
00:05:02,650 --> 00:05:10,030
Ution reached the end of the if statement, if the garbage collector gets triggered once good execution

66
00:05:10,030 --> 00:05:16,390
reaches the point marked by the arrow, it will identify two references stored on the stock and will

67
00:05:16,390 --> 00:05:18,520
include them in the application routes.

68
00:05:19,000 --> 00:05:26,200
The reference to the person object and the reference to the BBB screen it will start building the Reachability

69
00:05:26,200 --> 00:05:27,910
graph from those routes.

70
00:05:28,450 --> 00:05:35,320
The person object holds a reference to the thumb string, so it will also be included in the graph.

71
00:05:35,950 --> 00:05:43,540
No object in the graph holds the reference to a string, so it will be considered a candidate for removal

72
00:05:43,600 --> 00:05:44,890
by the garbage collector.

73
00:05:45,580 --> 00:05:50,740
Let's summarize to decide whether a reference pointing to some object exists.

74
00:05:51,010 --> 00:05:56,800
The garbage collector builds a graph of all objects reachable from route objects of the application,

75
00:05:57,040 --> 00:06:02,830
which are things like references currently stored on the stock or in static fields of glasses.

76
00:06:03,550 --> 00:06:10,300
If an object will not be included in this graph, it means it's not needed and can be removed from memory

77
00:06:10,720 --> 00:06:13,270
after the graph of suitability is built.

78
00:06:13,540 --> 00:06:20,210
The garbage collector can continue its work and remove the unreachable objects during the interview.

79
00:06:20,230 --> 00:06:24,670
You might have questions like What is the mark and sweep algorithm?

80
00:06:25,090 --> 00:06:28,120
Is the algorithm that the garbage collector implements.

81
00:06:28,480 --> 00:06:35,050
According to this algorithm, the garbage collector first marks objects that can be removed, and then

82
00:06:35,080 --> 00:06:36,790
it sweeps them from memory.

83
00:06:37,210 --> 00:06:41,050
How many stocks are there in a running application?

84
00:06:41,530 --> 00:06:43,780
There are as many stocks as threads.

85
00:06:44,110 --> 00:06:46,060
Each thread has its own stock.

86
00:06:47,130 --> 00:06:54,390
What to make an algorithm of identifying used and unused objects are implemented by tools similar to

87
00:06:54,390 --> 00:06:55,800
dotNet garbage collector.

88
00:06:56,520 --> 00:07:02,820
First is reference counting, which for each object holds a count of references pointing to it.

89
00:07:03,360 --> 00:07:06,870
An example of a language using this algorithm is swift.

90
00:07:07,530 --> 00:07:09,510
Another algorithm is tracing.

91
00:07:09,900 --> 00:07:16,380
This one is used in dotNet, which builds a graph of reachability starting from the application routes.

92
00:07:17,280 --> 00:07:17,940
All right.

93
00:07:18,240 --> 00:07:19,470
That's it for this lecture.

94
00:07:19,800 --> 00:07:24,570
Thanks for watching, and they'll see you in the next one when we'll continue the topic of the garbage

95
00:07:24,570 --> 00:07:25,200
collector.