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這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！