Consider this scenario: you want an application to drop into an idle state and release as much memory as possible, but you don’t want to shut it down completely because it may be called into action again at any time. This is the situation Andrew Au ran into when he proposed GCCollectionMode.Maximal. He described the problem as such:
Some of our components consumed some resources that could be freed. For example, the GC keeps some committed memory around to serve allocation requests. This is reasonable if the application is going on actively using memory, but it would be a waste if the application is going to be idle for a long period of time. In the container scenario, it would advantageous for the system as a whole if the idle process relinquishes as many resources as possible to increase deployment density.
When it was suggested the containers simply be turned off when unused, Michael Plaisted retorted:
This is possible for some scenarios but comes with downsides (cold start time, etc). This proposal would really help with workers we have running in Kubernetes reading messages off a queue that sit idle for significant periods of time. After processing a message they hold on to a significant amount of memory (an extra 500+ Mb in some cases) that doesn't get released. We may be able to get around this with a HPA that ignores memory and just checks CPU but would be nice not to have to add that complexity since the workers only actually require 1 milli cpu and ~25 Mb memory to keep warm and listening to the queue.
Renamed as GCCollectionMode.Aggressive, the feature was introduced in June for the .NET 7 release. To use it, invoke the following command:
GC.Collect(GCCollectionMode.Aggressive);
Note: At the time of writing, GCCollectionMode.Aggressive cannot be found in the official documentation. Visual Studio’s IntelliSense describes it as “Requests that the garbage collector decommit as much memory as possible.”.