JetBrains通过更好的垃圾回收机制来改善Kotlin/Native

这篇文章主要讲解了“JetBrains通过更好的垃圾回收机制来改善Kotlin/Native”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“JetBrains通过更好的垃圾回收机制来改善Kotlin/Native”吧！

在 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  应用程序时，将能够选择垃圾回收实现。

感谢各位的阅读，以上就是“JetBrains通过更好的垃圾回收机制来改善Kotlin/Native”的内容了，经过本文的学习后，相信大家对JetBrains通过更好的垃圾回收机制来改善Kotlin/Native这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！