在 2020 年，JetBrains 的 Kotlin 团队曾发布了重新设计 Kotlin/Native 中内存管理方法的计划。现如今，该团队则对其进展进行了更新，并分享了一些关于内存管理设计的细节。此外，官方透露，他们计划在 2021 年夏季结束前提供一个开发预览。

根据 JetBrains 的说法，最初的 Kotlin/Native 自动内存管理器使用了一个延迟引用计数的垃圾收集器，主要原因是在于它的简单性。然而，现在这个早期的设计选择已经成为提高 Kotlin/Native 性能和开发者体验的障碍，因此该团队正在寻求改进它。

博客内容指出，现代追踪式垃圾收集算法比引用计数式垃圾收集器更加灵活可调，并且更容易适应多线程应用程序的需求。但是，所有追踪式垃圾收集器都有一个共同的弱点--它们需要来自编程语言运行时和编译器的相当复杂的基础架构。

目前，Kotlin 团队正在研究新的基础架构。并透露，他们的第一个任务是确定 roots--内存中所有可以存储对动态分配内存的引用的位置。“这将使我们能够开始追踪一个对象图。”

同时，其还需要一个特殊的基础架构来实现并发垃圾回收算法，以避免阻塞应用程序的关键线程。“何苦？因为我们团队的主要使用场景是运行 UI 应用程序。UI 应用有一个 latency-sensitive 主线程，因此对于 Kotlin/Native 来说，仅支持 stop-the-world garbage collection 的设计是行不通的。”

因此，Kotlin 团队决定使用所谓的 safe points 方法，根据所有 roots 是否存储在可预测的位置，将编译后的代码染成 safe 或 unsafe。这些位置对运行时来说是已知的，这意味着垃圾回收可以与处于安全状态的代码并发运行。

重新设计的另一个目的则是实现与平台库的无缝互操作性。这需要内存管理器跟踪泄漏到 non-managed world 的自动管理内存的句柄，还需要支持弱引用，以及在自动管理的 Kotlin 对象有一个附加的平台特定对象的情况下运行额外的 deallocation code。

Kotlin 团队表示，其计划实现一种生产就绪的垃圾回收实现，支持线程之间无障碍地共享对象并满足所有其他设计目标。在未来，还可能会有一些受支持的垃圾收集算法，且这些算法都是针对不同的用例进行了优化。 

原有的 Kotlin/Native 内存管理方案将继续受到支持，以简化现有应用程序的迁移。因此，开发人员在构建 Kotlin/Native 应用程序时，将能够选择垃圾回收实现。

详情可查看官方博客：https://blog.jetbrains.com/kotlin/2021/05/kotlin-native-memory-management-update/