Kotlin/Native Memory Management Update
TL;DR: The original Kotlin/Native memory management approach was very easy to implement, but it created a host of problems for developers trying to share their Kotlin code between different platforms.
Back in 2020, we published our plan to rework the approach to memory management in Kotlin/Native. The original blog post describes the history that brought us to where we are now, listed the problems we were facing, and explained why we had to change our approach.
Now it is time to give an update on our progress and share some details about memory management design. Moreover, we plan to present a development preview by the end of summer 2021.
The very concept of automatic memory management is as old as programming languages. Early programming languages did not have the concept of a heap at all. All the memory was either statically or stack allocated. Developers did not have to think about memory allocation and deallocation at run time, as memory was either always allocated (statically) or automatically managed (via the stack) and nothing had to be done “manually”. This made things easy and simple, but it limited software to working with data of fixed sizes, and limits on the number of processed items had to be hard-coded in the source code.
PL/I in 1966 and Algol-68 were the first two major languages that added the concept of dynamically allocated memory as we know it today, establishing the tradition of manual memory management. This left it up to developers to write explicit code that allocates and frees memory in the heap.
