Hello.
In this video, we'll talk about Question eight, how does the garbage collector decide which objects
can be removed from memory?
As you hopefully know, the garbage collector is the common language runtime mechanism that is responsible
for memory management in different applications.
Its main role is to remove from the memory the objects that are no longer needed.
The algorithm it implements is called mark sweep because first it marks objects that can be removed
and the done sweeps them from memory.
But how can we tell if an object can be removed?
In simplest terms, when there are no existing references that point to this object?
But how can the garbage collector know it?
Well, in the family of tools similar to the garbage collector?
And remember, this concept is not exclusive to dot net.
There are two most commonly used algorithms.
The first is called reference counting, which, for example, is used in swift.
According to this algorithm, the garbage collector keeps track of the count of references pointing
to some object.
When the count, which is zero, it considers this object and referenced by another object and does
a candidate to be removed from memory.
There is a problem with this algorithm, though.
Imagine there are two objects A and B.
There is a reference from A to B and a reference from B to A.
And such reference is called circular reference.
But no other object in the application references A nor B, A and B objects could be removed from memory
because they cannot be reached from any point in the application, but signs for both of them.
The reference count is one, not zero.
A garbage collector using the reference counting algorithm would not remove them because of DOT, a
reference counting is not used in, not instead.
Tracing is used.
Tracing will determine whether an object is mutable or not by tracing it from a set of application routes.
We will learn what application roots are in a minute, but for now, let's just say there are objects
that the garbage collector starts building the graph of readability from.
If an object is reachable from a root object, either directly or indirectly, then it will be considered
alive.
If it's not reachable, it means it can be removed from memory.
Let's say that the garbage collector identifies pre-application application routes.
They, by definition, are considered suitable.
Then for each of them, the garbage collector chokes what references they hold, and it adds the objects
punctured by those references to the graph of readable objects.
It repeats this step for each of the new objects.
It continues its work until there are no more objects having references to objects that are not included
in the graph.
The power of this algorithm is that the circular references will not be included in the graph of heritable
objects because, well, they are not reachable.
All right, let's now see what application routes are exactly.
Routes includes static fields and local variables on the tract stuck to be more specific.
There are also a couple more things that will be included in the Application Roots collection, but
they come from a low level mechanism of C-sharp, which are beyond this conscious scope.
If you are curious, I linked a document about that intellectual resources.
For us, the most important part is local variables on the threat stack.
First thing we need to clarify each thread has its own stock, so in multi-threaded applications, we
will have more than one stack for simplicity.
Let's focus on single threaded applications.
The garbage collector will look at the stack and see what references are currently stored on it.
Remember, the reference itself is stored on the stock and it points to an object stored on the heap.
Let's consider this code execution point marked by the arrow.
The following references are stored on the stock.
The reference to the person object stored in the person variable.
The reference to the BBB string stored in the text variable and deformed references are not stored on
the stock.
The reference to the tongue string it is stored in the person object and the reference to the string
stored in the text inside.
If variable, it's not on the stock because it was removed from it.
Once Decode X.
Ution reached the end of the if statement, if the garbage collector gets triggered once good execution
reaches the point marked by the arrow, it will identify two references stored on the stock and will
include them in the application routes.
The reference to the person object and the reference to the BBB screen it will start building the Reachability
graph from those routes.
The person object holds a reference to the thumb string, so it will also be included in the graph.
No object in the graph holds the reference to a string, so it will be considered a candidate for removal
by the garbage collector.
Let's summarize to decide whether a reference pointing to some object exists.
The garbage collector builds a graph of all objects reachable from route objects of the application,
which are things like references currently stored on the stock or in static fields of glasses.
If an object will not be included in this graph, it means it's not needed and can be removed from memory
after the graph of suitability is built.
The garbage collector can continue its work and remove the unreachable objects during the interview.
You might have questions like What is the mark and sweep algorithm?
Is the algorithm that the garbage collector implements.
According to this algorithm, the garbage collector first marks objects that can be removed, and then
it sweeps them from memory.
How many stocks are there in a running application?
There are as many stocks as threads.
Each thread has its own stock.
What to make an algorithm of identifying used and unused objects are implemented by tools similar to
dotNet garbage collector.
First is reference counting, which for each object holds a count of references pointing to it.
An example of a language using this algorithm is swift.
Another algorithm is tracing.
This one is used in dotNet, which builds a graph of reachability starting from the application routes.
All right.
That's it for this lecture.
Thanks for watching, and they'll see you in the next one when we'll continue the topic of the garbage
collector.