Kotlin Multiplatform (KMP) is quickly gaining traction, with many large organizations adopting it for app development. However, for any app to run smoothly, it’s crucial to understand how it utilizes device resources. Neglecting to optimize this can lead to poor user experiences — crashes, lag, or even the operating system terminating the app when it runs in the background. If you’re considering using KMP in a production app, it’s essential to grasp how memory management works in a KMP environment.

This article is the first of a two-part series, where you’ll dive into the finer details of the Garbage Collector (GC) and its role in optimizing performance.

Basics

A Garbage Collector (GC) is a system used in many programming languages to automatically manage memory. It identifies and releases memory that’s no longer needed by a program, preventing memory leaks and improving performance. The GC monitors objects in memory, and when an object is no longer accessible or referenced, it deallocates that memory, making it available for other processes. This automation helps developers avoid the pitfalls of manual memory management, which can often be complex and error-prone.

While GC is a common feature in almost all programming languages, the way it operates can differ from one language to another. Now, for new developers, it’s worth noting that you don’t necessarily have to manually invoke the GC (though you can if you wish). Instead, it’s typically triggered by the language’s runtime environment, not by the operating system itself. This highlights a key point — GC behavior is language-triggered, not OS-triggered. So, it becomes crucial to understand how the GC works within the specific language you’re using.

This understanding becomes even more significant in cross-platform languages like Kotlin, where the garbage collection method varies between iOS and Android. In essence, GC is not only language-specific but also platform-specific.

In this part, we’ll primarily focus on the workings of the GC in Android, as it’s the core platform for Kotlin.

Understanding the Working of the Garbage Collector in Kotlin for Android

Since Kotlin is fully interoperable with Java, it inherits its memory management system from Android’s runtime environment. Unlike traditional JVM environments, Android uses the Android Runtime (ART), which employs its own garbage collection strategies tailored specifically for mobile applications.

ART and the Dalvik Garbage Collector

Android used to rely on the Dalvik Virtual Machine (DVM) before transitioning to ART in Android 5.0 (Lollipop). ART is designed to improve overall performance by employing more efficient garbage collection methods.

The ART garbage collector is optimized for mobile constraints such as limited CPU, memory, and battery. Some of the main garbage collection strategies used in ART include:

• Partial GC: Collects garbage from only the young generation (newer objects), which is usually faster and less disruptive to the user experience.
• Full GC: A more comprehensive garbage collection cycle that reclaims memory from the entire heap, including both young and old generations.
• Concurrent GC: Runs garbage collection concurrently with the application, reducing pause times that might otherwise cause noticeable stutters in UI performance.

How the Garbage Collector Works

1. Object Allocation: When an object is created, it is allocated memory in the heap. The application continues to reference this object as long as it is needed.
2. Object Reachability: The garbage collector continuously tracks the references to objects. Objects that are still referenced by running code are considered reachable and are not eligible for garbage collection.
3. Mark and Sweep: The GC uses a process called Mark and Sweep. During the mark phase, the garbage collector traverses all objects and marks those that are reachable. In the sweep phase, it collects all objects that are unmarked and frees the memory.
4. Generational Garbage Collection: The heap is divided into two generations:

• Young Generation: For newly created objects.
• Old Generation: For long-lived objects.

Most objects are short-lived and are quickly garbage-collected from the young generation. Objects that survive multiple garbage collection cycles in the young generation are moved to the old generation, where they are collected less frequently.

5. Compacting Memory: Once the unused objects are removed, the garbage collector may also compact the memory by rearranging the remaining objects. This helps in avoiding memory fragmentation and ensures efficient memory allocation for future objects.

Impact on Android Performance

While garbage collection in Kotlin (via the JVM) is automatic, it’s essential to understand that poorly managed memory can still degrade app performance. Here are some key considerations:

• Garbage Collection Pause: When the GC runs, it can cause a pause in the application’s execution, particularly if there are many objects to collect or the heap size is large. This can lead to jank (lag) in your Android UI if not managed properly.
• Memory Leaks: Even with garbage collection, memory leaks can still occur if references to unused objects are not released. A common cause is static references or long-lived objects like singletons that hold onto resources unnecessarily.
• Optimizing Object Creation: By minimizing unnecessary object creation, especially within tight loops or frequently called methods, you can reduce the pressure on the garbage collector. Reusing objects when possible is a good practice for reducing garbage collection overhead.

Conclusion

I won’t delve too deeply into Android’s garbage collection in KMP, as it functions similarly to that of a native Kotlin app, and there are plenty of resources available on this topic. In the next part, I’ll explore how garbage collection works in iOS apps built using KMP. Be sure to follow me to stay updated!

This article is previously published at proandroiddev.com