The Black Box of .NET

One framework to rule them all?

.NET 5 is on the way and scheduled to be delivered in November 2020. It is meant to unify .NET Framework, .NET Core, Mono (and possibly .NET Standard) - i.e. the entire .NET Platform.

After 17 years of working in .NET (since it was first released in 2002), I'm excited to see a unified solution to the splintered framework that .NET has become as of late. IMO, .NET Framework, .NET Core, .NET Standard, and Mono have grown into a big bad monster that is growing faster than its parts can manage. While we know (and expect) technology to evolve and grow over time, we hope that it doesn't fragment and splinter so much that its parts become dissimilar. I've seen it grow from a set of APIs that were questionable to something that is almost overwhelming - and certainly difficult to keep up with. I'm pleased to see that Microsoft has acknowledged the splintering and has been working on a solution since at least December 2018. I'm looking forward to seeing how much simpler things will become.

https://devblogs.microsoft.com/dotnet/introducing-net-5/

Now if they could just FINALLY fix "Edit and Continue"...........

(image is copyright of Microsoft)

You can determine which version of GC you're running via 2 methods:

calling the System.Runtime.GCSettings.IsServerGC property
attaching to the process using WinDbg and checking how many GC threads you have using the command "!sos.threads" without the quotes and (according to the below criteria)...

If you are running a Console app, WinForm app or a Windows Service, you will get the Workstation GC. Just because you are running on a Server OS doesn't mean that you will get the Server version of GC.

If your app is non-hosted on a multi-proc machine, you will get the Workstation GC - Concurrent by default.
If your app is hosted on a multi-proc machine, you will get the ServerGC by default.

The following apply to any given .NET Managed Process:

Workstation GC

Uni-processor machine
Always suspends threads
1 Ephemeral GC Heap (SOH), 1 LOH GC Heap
Runs on thread that triggered GC
Thread priority is the same as the thread that triggered GC

Workstation GC - Concurrent

Only runs concurrent in Gen2/LOH (full collection)
Mutually exclusive with Server Mode
Slightly larger working set
GC Thread expires if not in use after a while
1 Ephemeral GC Heap (SOH), 1 LOH GC Heap
Has a dedicated GC Thread
Thread priority is Normal

Server GC

Larger segment sizes
Faster than Workstation GC
Always suspends threads
1 Ephemeral GC Heap (SOH) for each logical processor (this includes hyperthreaded), 1 LOH GC Heap for each logical processor (this includes hyperthreaded)
Has dedicated GC Threads
Thread priority is THREAD_PRIORITY_HIGHEST

There is only 1 Finalizer thread per managed process regardless of GC Mode. Even during a concurrent GC, managed threads are suspended (blocked) twice to do some phases of the GC.

A seldom known fact is that even if you try to set the Server mode of GC, you might not be running in Server GC; the GC ultimately determines which mode will be optimal for your app and WILL override your settings if it determines your ServerGC setting will negatively impact your application. Also, any hosted CLR app will have any manual GC settings overridden.

In CLR 4.0, things change just a little bit

Concurrent GC is now Background GC
Background GC only applies to Workstation GC
Old (Concurrent GC):

During a Full GC Allowed allocations up to end of ephemeral segment size
Otherwise, suspends all other threads

New (Background GC):

Allows for ephemeral GC’s simultaneously with Background GC if necessary
Performance is much faster

Server GC always blocks threads for collection of any generation

In CLR 4.5, things change just a little bit...again

Background Server GC

Server GC no longer blocks. Instead, it uses dedicated background GC threads that can run concurrently with user code - see MSDN: Background Server GC

Thus, in .NET 4.5+, all applications now have background GC available to them, regardless of which GC they use.

.NET 4.7.1 GC Improvements

.NET Framework 4.7.1 brings in changes in Garbage Collection (GC) to improve the allocation performance, especially for Large Object Heap (LOH) allocations. This is due to an architectural change to split the heap’s allocation lock into 2, for Small Object Heap (SOH) and LOH. Applications that make a lot of LOH allocations, should see a reduction in allocation lock contention, and see better performance. These improvements allow LOH allocations while Background GC (BGC) is sweeping SOH. Usually the LOH allocator waits for the whole duration of the BGC sweep process before it can satisfy requests to allocate memory. This can hinder performance. You can observe this problem in PerfView’s GCStats where there is an ‘LOH allocation pause (due to background GC) > 200 msec Events’ table. The pause reason is ‘Waiting for BGC to thread free lists’. This feature should help mitigate this problem.