Microsoft and Garbage Collection

The .NET software environment handles memory management by itself, running tests and detecting when it’s safe to free up memory. As long as a process references an object stored in memory, the object is considered to be in use and is not considered garbage. However, when a process has no references to an object and the object in fact cannot be used, it is considered garbage and is picked up and cleaned out by the GC.

The GC runs intermittently on a separate thread from the app that’s in use, and it runs only when memory needs to be freed up. To determine when this is the case, the GC pauses the application and tests to see which objects are reachable. It also counts all objects. The objects that are determined not to be reachable are classified as garbage, and the memory where those objects reside can be emptied out and freed up.

When Is Garbage Collection Initiated?

Three scenarios can trigger the GC:

• Low physical memory in the system
• When the threshold indicating an acceptable level of memory suitable for use by allocated objects is surpassed
• The GC can be explicitly triggered by a program, but only very rarely is this necessary

In short, the GC is triggered when it determines that it would be prudent to free up memory.

The chunks of memory that are cleaned out by the GC aren’t necessarily contiguous. This means that garbage collection leaves gaps of free space between objects that used to be contiguous. However, the GC knows to compact these objects together so that the objects are contiguous and free space is contiguous once again. An application is paused for the GC to do its job and, as soon as garbage collection is finished, the application resumes automatically. These pauses are designed to be unnoticeable to app users, because garbage collection is run in the background.

What Happens to Running Programs When Garbage Collection Is Initiated?

In earlier versions of the .NET software environment, garbage collection required safely suspending all threads in a running program first. As you might imagine, this resulted in latency in programs, which could be frustrating to users. However, in more recent versions of the .NET framework, changes were made to the GC to minimize these problems. Now, dedicated background GC threads run concurrently with user code, so that any pauses are much shorter and less noticeable. The environment can still get fully blocked up if there’s enough pressure on the memory, but it’s much rarer with newer versions of .NET.

Does Your Web Development Partner Understand the .NET Garbage Collector?

A good .NET developer understands that your business doesn’t have time for latency, and makes sure the app and the GC run in harmony so that you experience fewer, shorter pauses – pauses so brief as to go unnoticed. The .NET GC made it so developers don’t have to worry about explicit memory management, but they must still be aware of how and when the GC does its job to fully avoid memory and performance issues.