Background and motivation

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.

API Proposal

I am proposing to add a new enum value on GC.CollectionMode as follows:

public enum GCCollectionMode
{
  // ...
  Maximal
}

When the GC receives this value, it will try to decommit as much memory as it can.

API Usage

GC.Collect(GCCollectionMode.Maximal);

Alternative Designs

Initially, I was proposing an API like this:

bool System.AppContext.Idle { get; set; }

System.EventHandler System.AppContext.Idle.OnIdleChanged(object sender, EventArgs args);

This allowed the individual subsystems (e.g. libraries) to subscribe to the event and perform the necessary release. GC could then be the last one, after all the resources have been released, and then finally we clean up the memory.

The advantage of such an API would be the ease of use for an operator. In that case, he doesn't need to figure out the individual pieces to release resources.

The disadvantage of such an API is that the library authors have to make many policy decisions, such as to what extent to release the resources. It might fit some customers but not fit others. It is difficult to make a one size fit all solution.

We can easily regain the advantage by having a consolidated list to document the best practice for releasing resources and entering the idle state.

Risks

Misuse of this API may lead to frequent commit/decommit of memory, and that is expensive.