The Kotlin team at JetBrains has detailed plans to implement a new memory management approach for Kotlin/Native, its tool for compiling Kotlin code to native binaries that can run without a virtual machine.

According to JetBrains, the original Kotlin/Native automatic memory manager uses a deferred reference-counting garbage collector, chosen principally for its simplicity. However, this early design choice has become a roadblock to improving Kotlin/Native’s performance and developer experience, and so the team is looking to improve on it.

Modern tracing garbage collection algorithms are much more flexible and can be tuned much more readily than reference-counting garbage collectors, but they come with the downside of requiring fairly complex infrastructure from a programming language runtime and a compiler.

The Kotlin team is developing this infrastructure, beginning with identifying roots – the locations in memory where a reference to a dynamically allocated memory can be stored – which will allow the tracing of an object graph.

The new approach, said JetBrains, will also call for concurrent garbage collection algorithms to avoid blocking the critical threads of an application, as Kotlin Project Lead Roman Elizarov explained on the Kotlin Blog.

“Why bother? Because the main usage scenario for our team is running UI applications. UI applications have a latency-sensitive main thread, so a design that only supports stop-the-world garbage collection is a no-go for Kotlin/Native,” he said.

Because of this, the Kotlin team has decided to use a safe points approach, where the compiled code is coloured as safe or unsafe according to whether all roots are stored in predictable locations. These locations will be known to the runtime, meaning that garbage collection can run concurrently with the code that is in a safe state.

Meanwhile, another goal of the redesign is to implement seamless interoperability with platform libraries. This requires the memory manager to keep track of handles to automatically-managed memory that leaks to the non-managed world, said Elizarov, as well as support for weak references and for running additional deallocation code in cases when an automatically-managed Kotlin object has an attached platform-specific object.

JetBrains said it aims to offer a public development preview by the end of summer 2021. This will not be production-ready, as it will be focused on correctness rather than performance.

Looking ahead, the team intends to implement a production-ready garbage collection implementation that supports the unimpeded sharing of objects between threads and meets all other design goals.

JetBrains will continue to support the original Kotlin/Native memory management scheme to simplify migration of existing applications, so developers will be able to choose the garbage collection implementation when building applications. In future, there may even be a number of supported garbage collection algorithms optimised for different use cases, said Elizarov.