Table of Contents

.NET Core – Garbage Collection

”;

In this chapter, we will cover the concept of Garbage collection which is one of most important features of the .NET managed code platform. The garbage collector (GC) manages the allocation and release of memory. The garbage collector serves as an automatic memory manager.

You do not need to know how to allocate and release memory or manage the lifetime of the objects that use that memory
An allocation is made any time you declare an object with a “new” keyword or a value type is boxed. Allocations are typically very fast
When there isn’t enough memory to allocate an object, the GC must collect and dispose of garbage memory to make memory available for new allocations.
This process is known as garbage collection.

Advantages of Garbage Collection

Garbage Collection provides the following benefits −

You don’t need to free memory manually while developing your application.
It also allocates objects on the managed heap efficiently.
When objects are no longer used then it will reclaim those objects by clearing their memory, and keeps the memory available for future allocations.
Managed objects automatically get clean content to start with, so their constructors do not have to initialize every data field.
It also provides memory safety by making sure that an object cannot use the content of another object.

Conditions for Garbage Collection

Garbage collection occurs when one of the following conditions is true.

The system has low physical memory.
The memory that is used by allocated objects on the managed heap surpasses an acceptable threshold. This threshold is continuously adjusted as the process runs.
The GC.Collect method is called and in almost all cases, you do not have to call this method, because the garbage collector runs continuously. This method is primarily used for unique situations and testing.

Generations

The .NET Garbage Collector has 3 generations and each generation has its own heap that that is used for the storage of allocated objects. There is a basic principle that most objects are either short-lived or long-lived.

Generation First (0)

In Generation 0, objects are first allocated.
In this generation, objects often don’t live past the first generation, since they are no longer in use (out of scope) by the time the next garbage collection occurs.
Generation 0 is quick to collect because its associated heap is small.

Generation Second (1)

In Generation 1, objects have a second chance space.
Objects that are short-lived but survive the generation 0 collection (often based on coincidental timing) go to generation 1.
Generation 1 collections are also quick because its associated heap is also small.
The first two heaps remain small because objects are either collected or promoted to the next generation heap.

Generation Third (2)

In Generation 2, all long objects are lived and its heap can grow to be very large.
The objects in this generation can survive a long time and there is no next generation heap to further promote objects.
The Garbage Collector has an additional heap for large objects known as Large Object Heap (LOH).
It is reserved for objects that are 85,000 bytes or greater.
Large objects are not allocated to the generational heaps but are allocated directly to the LOH
Generation 2 and LOH collections can take noticeable time for programs that have run for a long time or operate over large amounts of data.
Large server programs are known to have heaps in the 10s of GBs.
The GC employs a variety of techniques to reduce the amount of time that it blocks program execution.
The primary approach is to do as much garbage collection work as possible on a background thread in a way that does not interfere with program execution.
The GC also exposes a few ways for developers to influence its behavior, which can be quite useful to improve performance.

Print Page