Garbage collection

Garbage collection (GC) is one of the most effective automated memory management techniques on modern application development platforms. In simple terms, with automated garbage collection, memory resources are allocated for objects used by the application and reclaimed for resources no longer needed by the application.

Note

In spite of the fact that garbage collection, as an automated process, takes over the burden of managing memory allocations, it can have a significant impact on performance. This performance handicap is one of the main reasons why there is no garbage collection mechanism on the iOS platform.

In theory, GC is responsible for reclaiming memory resources occupied by runtime elements that cannot be reached by the current executing application. However, this mechanism cannot always identify these unreachable resources correctly and/or have unexpected results while purging the identified memory pointers.

Memory leaks occur when an application fails to identify and/or free the resources occupied by unreachable code elements, which can lead to memory exhaustion problems.

Dangling pointers happen when a memory region is freed while references still exist in the execution context. These references are then removed and memory can be re-allocated for another use.

Double free bugs occur when a memory region is already reclaimed and the application or garbage collector tries to free this region once more.

GC on Xamarin projects

Managed code, as defined by the Common Language Runtime in the .NET framework, is application code where the memory resources are managed by the native garbage collector. GC, on initialization, allocates a segment of the memory to store and manage memory resources, which is called the "managed heap". The garbage collection in CLR happens on three different generations where objects with different lifespans live in the heap. Promotion between the generation and survival of objects depend on which generation they are placed in and how they survived prior GC cycles.

SGen garbage collector

SGen garbage collector is the generational garbage collector used in most Xamarin projects (both Xamarin.iOS and Xamarin.Android). SGen performs more frequent garbage collections over smaller sets of objects which makes it more efficient over the conservative Boehm GC.

SGen utilizes three heaps, namely The Nursery, Major Heap, and Large Object Space, to allocate memory segments for objects according to their memory requirements, and objects are promoted between the heaps when they survive through GC cycles. In this setup, The Nursery, similar to Generation 0 in CLR on .NET, is where most objects are created and destroyed and most of the GC cycles occur to release memory resources. Objects surviving the minor GC cycles can be promoted to the major heap. The major heap only has major GC passes in case the heap itself is running out of memory. The last heap is only for larger objects that have higher memory requirements, and does not accept promotion from other heaps.

Note

It is important to remember that during a garbage collection cycle all the threads registered with the runtime, including the main run loop thread are paused. One exception to this execution pause is the separate process that continues to run the iOS animations.

Boehm garbage collector (iOS only)

Boehm GC (aka Boehm-Demers-Weiser garbage collector) is an open-source garbage collector implementation that was initially created for C/C++ language implementations. As a conservative garbage collector, it still has procedures for leak detection, supports "finalized" semantics, and has limited support for generational implementations which makes it an attractive candidate for implementations and ports on various platforms.

An implementation of Boehm GC is only available for Xamarin.iOS applications using the Classic API, in which it is the default garbage collector.