skip to Main Content

Garbage Collection Types in .Net Core

Memory management in modern languages is often an afterthought. For all intents and purposes, we write software without nary a thought about memory. This serves us well but there are always exceptions…

In California, there are extensive financial reporting requirements for Local Education Agencies (LEA), an LEA can be a county, a district, a charter or a single school. Most LEAs create their own financial reports which are usually centered around Excel, it’s no surprise when each report is different. To solve this problem the California Board of Education commissioned software to generate financial reports. 

I was a part of the development team. 

My first stop was the testing logs, Ed-Pro’s logs pointed to high memory usage, perhaps there was a memory leak? An engineer observed that Ed-Pro’s calculations used a large amount of short-lived memory. If the memory wasn’t cleaned up quickly, it could appear like a memory leak.

Ed-Pro is built on top of .Net Core, Microsoft’s multi-platform framework. In .Net Core, memory is divided into three categories: Short-lived (Gen0), medium lived (Gen1), and long-lived (Gen2). Gen0 is for short-lived data that quickly goes out of scope, Gen1 is for medium lived memory that hangs around for a bit longer, it too also eventually goes out of scope and Gen2 is long-lived memory that may live for the life of the application. Gen0 memory is constantly reclaimed, Gen1 is reclaimed less frequently than Gen0, and Gen2 is reclaimed even less frequently than Gen1.

The only sure way to understand the memory usage of Ed-Pro was to profile it, below is a screenshot using dotMemory by JetBrains.

As suspected, we found large amounts of Gen0 memory (the blue), so much so, it appeared that Garbage Collection couldn’t keep up. A strategy to compensate for a large amount of memory, caused Garbage Collection to oscillated between increasing memory space (adding more memory for the application’s use) and cleaning it up. During the cleanup cycles, the application is unresponsive.

At first, we were stumped, isn’t the purpose of the GC to keep memory tidy? Two articles were instrumental in our understanding of how Garbage Collection works in .Net: Mark Vincze’s article Troubleshooting high memory usage with ASP.Net Core on Kubernetes and Fundamentals of Garbage Collection by Microsoft. Both are great reads and brought clarity to the memory usage in Ed-Pro. 

Here’s a summary of what we learned, there are two types of Garbage Collection in .Net: Server Garbage Collection and Workstation Garbage Collection.

Server Garbage Collection makes a couple of assumptions: First, there is ample memory available and second, the processors are multi-core and are fast. Both can be true, but we live in a world of virtual machines and Docker where it’s more likely that both assumptions are false.

Server Garbage Collection allows memory to build, at some point, it does one of two things: it either increases the memory space allowing memory to grow or it frees up orphaned memory. When it chooses to free memory, the Garbage Collection starts the process on a high priority thread. The high priority thread is a higher priority than the application; if the machine is fast, the clean up shouldn’t be noticed. However, if it’s not, it’ll cause the application to halt until the clean up is completed.

Workstation Garbage Collection operations differently. It continuously runs reclaiming memory on a thread with the same priority as the application. This means it’s also competing for resources with the application which can cause application slowness. The upside is the application’s memory usage can stay quite low, primarily when it uses large amounts of Gen0.

As a default, if .Net Core detects a server, it runs the Server Garbage Collection type, which was the case with our application. To run the Workstation Garbage Collection type add the following snippet to your project file:

  <PropertyGroup> 
    <ServerGarbageCollection>false</ServerGarbageCollection>
  </PropertyGroup>

We made this configuration change to Ed-Pro, using dotMemory, we profiled Ed-Pro’s memory with Workstation Garbage Collection enabled and loaded the same screens as in the previous test. Here are the results:

The memory usage is significantly decreased. The Gen0 allocations are virtually non-existent. Beyond the differences in the graph, the Server Garbage Collection memory usage topped 1 gig while the Workstation Garbage Collection topped at roughly 200 megs.

Every application is different. Our application used a ton of temporary data and thus uses a ton of Gen0 memory. Your application may leverage longer lived memory such as Gen1 or Gen2 in which Server Garbage Collection makes a whole lot of sense. My advice is to profile your memory under different conditions for an idea of how memory is used and then decide which mode is best for you application.

You Are Not Your Code

It’s not personal.

Your code reflects neither your beliefs, nor your upbringing, nor your character.

Your thoughts and your opinions evolve, new ideas form, and you change. 

The you of today will be different from the you of tomorrow.

Embrace the difference, you and your code are better because it.

The 5 Different Meanings of the Question Mark in C#

In C# the question mark has 5 meanings as of C# 8.

  1. Ternary operators
(true ? "true": "false")

2. Null conditional operator

items?.Count()

3. Nullable types (this should be rebranded as nullable value types)

int?

4. Null-coalescing operator

isnull ?? string.Empty

5. Nullable reference types

string?

The Collection Comparer, Finding the Differences Between Two Collections

Have you had to compare two collections and execute some logic based on whether the item is in the source collection, in the comparing collection or in both? Yeah, me too, I needed to merge data from the UI and the database. I couldn’t find a good solution, so, I wrote a collection comparer.

To illustrate how this works let’s look at an example.

In the source data we have the values 1, 3, 4, 6, and in the
comparing collection we have the values 1, 2, 3, 4, 5.

The source data is missing the 2 and the 5 when compared to the comparing collection, and the comparing collection is missing the 6 when compared to the source collection.

Let’s walk through this merge:

  1. in both (update)
  2. only in the comparing collection (add to source)
  3. in both (update)
  4. in both (update)
  5. only in the comparing collection (add to source)
  6. only in the source collection (remove from source)

Here what the code looks like:

var source = new []{1, 3, 4, 6};
var collection = new[] {1, 2, 3, 4, 5};

source.CompareTo(collection, (s, d) => s == d)
    .OnlyInSourceCollection(s=> {/* do something */})
    .OnlyInComparingCollection(s=>{/* do something */})
    .InBoth(s=> {/*do something*/})
    .Process();

Why not use LINQ?

You can use LINQ, however, LINQ will iterate the collections at least 3 times which doesn’t include operating (adding, updating, and deleting) on the data. Using the CollectionComparer, the data is only iterated twice.

There are faster ways to find the differences such as a binary search, but a binary search only works with integers. The collection comparer supports any type of comparison. The comparison is defined with this code: (s, d) => s == d.

The source code is found on GitHub.

Implementing Request Caching in ASP.Net Core

At some point in an application’s development, usually, fairly early on, you realize the application is slow. After some research, the culprit is, unnecessarily retrieving the same data, and a light goes off, and you think: “I need some caching.”

Caching is an invaluable pattern for eliminating redundant calls to a database or a third party API. Microsoft provides IMemoryCache for time-based caching, however sometimes time-based caching isn’t what you need. In this article, we look at Request Scoped caching and how it can benefit us.

What is Request caching? Request caching is a mechanism to cache data for the life of a web request. In dot-net, we’ve had this ability in some capacity with the HttpContext.Items collection, however, HttpContext is not known for its injectability.

Request Scoped caching has a few benefits: First, it eliminates the concern of stale data. In most scenarios, a request executes in less than a second and which typically isn’t long enough for data to become stale. And secondly, expiration isn’t a concern because the data dies when the request ends.

Out of the box, Asp.Net Core doesn’t have injectable caching. As mentioned earlier, HttpContext.Items is an option, but it’s not an elegant solution.

Luckily for us, ASP.Net Core gives us the tools to create an injectable Request Caching implementation by using the built-in dependency injection (DI) framework.

The built-in DI framework has three lifetimes for dependencies: Singleton, Scoped, and Transient. Singleton is for the life of the application, Scoped is for the life of the request and Transient is a new instance with each request.

I’ve created an interface modeled after the IMemoryCache interface to keep things consistent.

Interface

public interface IRequestCache
{
    /// <summary>
    /// Add the value into request cache. If the key already exists, the value is overwritten.
    /// </summary>
    /// <param name="key"></param>
    /// <param name="value"></param>
    /// <typeparam name="TValue"></typeparam>
    void Add<TValue>(string key, TValue value);

    /// <summary>
    /// Remove the key from the request cache
    /// </summary>
    /// <param name="key"></param>
    void Remove(string key);

    /// <summary>
    /// Retrieve the value by key, if the key is not in the cache then the add func is called
    /// adding the value to cache and returning the added value.
    /// </summary>
    /// <param name="key"></param>
    /// <param name="add"></param>
    /// <typeparam name="TValue"></typeparam>
    /// <returns></returns>
    TValue RetrieveOrAdd<TValue>(string key, Func<TValue> add);

    /// <summary>
    /// Retrieves the value by key. When the key does not exist the default value for the type is returned.
    /// </summary>
    /// <param name="key"></param>
    /// <typeparam name="TValue"></typeparam>
    /// <returns></returns>
    TValue Retrieve<TValue>(string key);
}

Implementation

public class RequestCache : IRequestCache
{
    IDictionary<string, object> _cache = new Dictionary<string, object>();

    /// <summary>
    /// Add the value into request cache. If the key already exists, the value is overwritten.
    /// </summary>
    /// <param name="key"></param>
    /// <param name="value"></param>
    /// <typeparam name="TValue"></typeparam>
    public void Add<TValue>(string key, TValue value)
    {
        _cache[key] = value;
    }

    /// <summary>
    /// Remove the key from the request cache
    /// </summary>
    /// <param name="key"></param>
    public void Remove(string key)
    {
        if (_cache.ContainsKey(key))
        {
            _cache.Remove(key);
        }
    }

    /// <summary>
    /// Retrieve the value by key, if the key is not in the cache then the add func is called
    /// adding the value to cache and returning the added value.
    /// </summary>
    /// <param name="key"></param>
    /// <param name="add"></param>
    /// <typeparam name="TValue"></typeparam>
    /// <returns></returns>
    public TValue RetrieveOrAdd<TValue>(string key, Func<TValue> add)
    {
        if (_cache.ContainsKey(key))
        {
            return (TValue)_cache[key];
        }

        var value = add();

        _cache[key] = value;

        return value;
    }

    /// <summary>
    /// Retrieves the value by key. When the key does not exist the default value for the type is returned.
    /// </summary>
    /// <param name="key"></param>
    /// <typeparam name="TValue"></typeparam>
    /// <returns></returns>
    public TValue Retrieve<TValue>(string key)
    {
        if (_cache.ContainsKey(key))
        {
            return (TValue)_cache[key];
        }

        return default(TValue);
    }
}

Using ASP.Net Core’s DI framework we’ll wire it up as Scoped.

services.AddScoped<IRequestCache, RequestCache>();

Usage

public class UserService
{
    private readonly IRequestCache _cache;
    private readonly IUserRepository _userRepository;

    public UserService(IRequestCache cache, IUserRepository userRepository)
    {
        _cache = cache;
        _userRepository = userRepository;
    }

    public User RetrieveUserById(int userId)
    {
        var buildCacheKey = UserService.BuildCacheKey(userId);

        return _cache.RetrieveOrAdd(BuildCacheKey, () => { return _userRepository.RetrieveUserBy(userId); });
    }

    public void Delete(int userId)
    {
        var buildCacheKey = UserService.BuildCacheKey(userId);

        _userRepository.Delete(userId);
        _cache.Remove(BuildCacheKey(userId));
    }

    private static string BuildCacheKey(int userId)
    {
        return $"user_{userId}";
    }
}

That’s it! Request Caching is now injectable in any place you need it.

Visit the Git Repository and feel free to take the code for a spin.

Back To Top