IT资讯 JetBrains 旨在通过更好的垃圾回收机制来改善 Kotlin/Native

archibald · 2021-05-26 10:00:06 · 热度: 24

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

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

根据 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/

猜你喜欢:
暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册