Analysis Overview

Pinned objects in Gen0

In some cases, for example, when working with unmanaged code (say, an external library) from the managed code, your application may allocate the so-called pinned objects. Such objects are "pinned" in the small object heap – they cannot be moved in the heap as the managed code relies on the exact position of such objects. This leads to a negative consequence – Garbage Collector cannot compact the small object heap. This may result in more often and less efficient GCs reducing the overall application performance.

For example, we have the following objects layout in the Gen0: [A][B][Pinned][C][D]. The objects [A] and [B] cannot be collected until the [Pinned] object is removed from the heap.

dotMemory is able to automatically detect allocation of pinned objects in the Gen0 segment of the managed heap.

The possible origin of the pinned objects:

• You can intentionally create pinned objects using the fixed block:

  unsafe { var buffer = new byte[2000]; fixed (byte* ptr = buffer) { ... } }

• You create a GCHandle to an object that prevents it from garbage collection:

  var buffer = new byte[2000]; var gCBuffer = GCHandle.Alloc(buffer, GCHandleType.Pinned);

Possible solutions:

• If possible, consider using stackalloc to allocate the buffer on the stack instead of the heap:

  var buffer = stackalloc byte[2000];

• If the buffer contains pinned objects, it may be more reasonable to allocate it on the Large Object Heap instead of the Small Object Heap. To do so, make the buffer larger than 84 KB.

High GC pressure

High GC pressure is the situation when garbage collection is performed too often and takes a significant amount of time. Namely, when the time spent on garbage collection takes more than 30% of the overall execution time during some sample certain time interval.

The typical causes:

• The program creates a lot of short-living objects, for example closures in a loop.

• The program is close to Out of Memory.

The possible solution is to revise your code to prevent frequent allocations. You can find more examples of such issues in this series of blog posts:

• Unusual Ways of Boosting Up App Performance. Boxing and Collections

• Unusual Ways of Boosting Up App Performance. Strings

• Unusual Ways of Boosting Up App Performance. Lambdas and LINQs

• Analyzing Ineffective Memory Usage with dotMemory

• String Interning: Effective Memory Management with dotMemory

Fast LOH growth rate

The Large Object Heap (LOH) is a special segment of the managed heap that stores large objects (>84 KB). dotMemory tracks the growth of LOH in real-time. If LOH grows too fast, it may become heavily fragmented and end up in throwing the OutOfMemory exception.

The typical cause:

Dynamically-sized collections such as Dictionary, List, HashSet, and StringBuilder have the following specifics: When the collection size exceeds the current bounds, .NET resizes the collection and redefines the entire collection in memory.

The possible solution could be reducing the number of cases when the resize is needed. Try to predict the required size and initialize a collection with this size or larger.