The idea of the Blocking GC filter is to "Select all time intervals where blocking garbage collection was (or was not) performed". For example, if you want to analyze only time intervals where blocking garbage collection took place, select the Blocking GC intervals in the filter.
There are three options depending on the GC state:
Blocking garbage collection is performed. All threads except the one that toggled the collection are suspended.
Exclude Blocking GC
No blocking garbage collection is performed. Application is running.
As runtime could be either blocked or not blocked by GC, this state can be described as "the filter is not applied".
The percentage of time the threads were and/or blocked by garbage collection relative to the total selected time.
GC Concepts in Brief
- For desktop applications, .NET Framework offers a so-called workstation GC mode.
- There are two types of workstation garbage collection: foreground and background.
- To perform a foreground GC, garbage collector suspends all managed threads except the one that triggered the collection. This suspends the main thread as well and leads to a UI freeze. This is a "pure" blocking GC.
- Background GC is performed by a separate GC thread and does not suspend managed threads during the "heaviest" Gen2 collections. Nevertheless, during Gen0 and Gen1 collections managed threads have to be suspended. Thus, background GC still involves short "blocking GC" intervals. By default, background GC is turned on.
- For server applications, there is a special server GC mode. The main difference comparing to workstation GC is that in the server GC mode each logical processor has its own managed heap and a separate GC thread. From the point of performance analysis in Timeline Viewer, there are no huge differences between background and server GC.
Learn more about GC types on MSDN.
In performance analysis, you are not really interested in distinguishing foreground and background GCs. It makes more sense to analyze only the time intervals of blocking garbage collections as they lead to UI freezes. That is why, Timeline Viewer offers the Blocking GC filter. Nevertheless, you can analyze background GCs separately using the Interval Filters | Background GC filter.
Let us take a look at how Blocking GC and Interval Filters | Background GC filters calculate GC time. For example, your application has two threads: User Thread#1 and User Thread#2. At some point, to free up some memory, User Thread#1 toggles blocking Gen0, Gen1 garbage collection (the A1 interval on the diagram below). As memory is still not enough, a GC thread is created. It performs full GC which includes the Gen0, Gen1 blocking collections (C3) and the Gen2 collection (B3 and D3) which does not block other threads.
Not Selected = (X1 + X2) + (A1 + A2) + (B1 + B2 + B3) + (C1 + C2 + C3) + (D1 + D2 + D3) + (Y1 + Y2 + Y3)
Blocking GC = (A1 + A2) + (C1 + C2 + C3)
Exclude Blocking GC = (X1 + X2) + (B1 + B2 + B3) + (D1 + D2 + D3) + (Y1 + Y2 + Y3)
Note that Background GC is calculated only for the GC thread.
Let us take a look at a more elaborate example. For instance, your application has two threads you are interested in: Thread#1 and Thread#2. Profiling lasted 50 ms. During this time, Thread#1 toggled garbage collection that lasted 10 ms. This blocked Thread#2 for these 10 ms. During the other 40 ms, Thread#2 was in the running state. The Blocking GC filter for these two threads will look like follows:
As Thread#1 toggled GC, it is considered Running during the blocking GC time. This peculiarity allows you to determine threads that toggled GC.
To apply the Blocking GC filter:
- Select the desired filter value.
For example, on the picture above, the Blocking GC filter helps to determine the cause of garbage collections. As you can see, after selecting Blocking GC, the filter leaves two time intervals for Thread#1. During the first one, the thread is Waiting which means the thread was blocked by GC toggled by some other thread. During the second one, the thread is Running which means it toggled this GC by itself.