システムプログラマのためのガベージコレクション (2023)

 (bitbashing.io)
4 ポイント 投稿者 GN⁺ 2024-03-31 | 1件のコメント | WhatsAppで共有

RCU の紹介

  • オペレーティングシステムは、日々動作するプログラムの中でも最も性能に敏感なものの一つである。
  • オペレーティングシステムは常にさらに高速化でき、カーネルやドライバの開発者はコード最適化に取り組んでいる。
  • オペレーティングシステムには大規模な並行性が必要であり、ユーザー空間のプロセスやスレッドをスケジューリングし、自身のスレッドやハードウェアと相互作用する割り込みハンドラを持つ。

RCU の動作原理

  • 頻繁に読まれるがめったに書き換えられないデータ（例: 現在接続されている USB デバイス）を原子的に変更する必要があるとき、RCU（Read, Copy, Update）戦略を使用する。
  • データを読み取り、コピーして変更した後、ポインタを新しいバージョンへ原子的に更新する。
  • この方法は使いやすく待ち時間もないが、メモリリークが発生する可能性がある。

メモリリーク問題の解決

  • メモリリークを防ぐため、更新関数内で古いデータを削除する代わりに、現在それを読んでいるリーダーがいなくなったときに削除するよう遅延させることができる。
  • リーダーがデータを読んでいる間、ライターはデータ削除を待つことで安全にメモリを管理する。

RCU の実際の利用

  • RCU は Linux で何万回も使われており、Facebook の Folly C++ ライブラリや Rust の crossbeam-epoch でも使われている。
  • RCU は性能とレイテンシ要件によって採用されており、ガベージコレクションに似たメモリ管理方式を提供する。

ガベージコレクションに関する誤解

  • ガベージコレクションが手動メモリ管理より遅いという通念は、細部を見るとすぐに崩れる。
  • free() 関数は無料ではなく、メモリアロケータは内部的に多くの状態を維持しなければならない。
  • 現代のガベージコレクションは移動および世代別最適化を提供し、高いスループットとキャッシュ性能を実現する。

制御の幻想

  • 開発者はときにリアルタイムシステムを構築しようとするが、実際にはメモリ管理を完全に制御できているわけではない。
  • オペレーティングシステムはメモリ割り当てに対する開発者の意図を推測するだけであり、単純なポインタアクセスがディスク I/O に変わることさえある。

結論

  • すべてのソフトウェアがガベージコレクションの恩恵を受けるわけではないが、ガベージコレクションは有用なツールであり、システムプログラマの間でももはや恐れる必要はない。

GN⁺の見解

  • RCU は、マルチスレッド環境でデータ整合性を保ちながら並行性を高める効果的な手法である。これは高性能計算やリアルタイムシステムで非常に重要な要素である。
  • ガベージコレクションに関する通念を打ち破る RCU の例は、開発者にメモリ管理への新たな視点を提供する。これは特に、メモリ管理が重要なシステムプログラミング分野でよりいっそう当てはまる。
  • RCU と似た機能を提供する他のプロジェクトとして、Java の ConcurrentLinkedQueue や .NET の ConcurrentBag などがあり、これらもロックフリー（lock-free）なデータ構造を提供する。
  • RCU 技術を導入する際には、システムの要件と性能目標を考慮し、この技術を使うことで得られる利点と潜在的なコストを理解する必要がある。
  • この記事は、開発者がメモリ管理と並行性についてより深く理解し、既存の前提を見直し、新しい解決策を探る助けとなりうる。

関連記事

1件のコメント

 
GN⁺ 2024-03-31
Hacker Newsの意見

  • MPLとMaPLeに関する革新的な並列ガベージコレクション（GC）技術をチェックするべきという提案

    • POPL 2024でDistinguished Paper AwardとACM SIGPLAN 2023 Test of Time Awardを受賞
    • 主な提案は次の通り:
      • 証明可能に効率的な並列ガベージコレクションに基づくdisentanglement
      • 証明可能に効率的な自動粒度制御

  • RCUをガベージコレクションの同期機構として使うのは興味深い

    • 最後のリーダーに、ライターからメモリ解放の責任を移すのは理にかなっている
    • 性能向上のため、メモリ解放をリーダーではなく専用のバッチ処理プロセスに移すことを検討すべきかもしれない

  • メモリ管理に関する一般的な誤解

    • プログラマーがメモリ管理のための最適な停止時間を知っていると信じていること
    • ゲームや暗号資産取引プログラムでは、プログラマーが実際に最適な停止時間を把握している可能性がある

  • RCUのユースケースには説得力があるが、他の状況でのガベージコレクションの経験は良くない

    • カスタムなメモリ管理ソリューションが最高の性能を提供しうるという主張として読める
    • free()呼び出しがメモリをOSに返すという誤解についての議論

  • ガベージコレクションを使うと、新しい割り当てがキャッシュではなくRAMから行われる

    • 性能に大きな影響を与える可能性がある
    • Julia言語でのベンチマーク例が示されている

  • 優れたトレーシングガベージコレクタは、スループットの面ではかなり前から手動メモリ管理を上回っている

    • 最近では、ほとんどのアプリケーションでレイテンシも許容範囲にある
    • 主な考慮事項はメモリ使用量

  • ガベージコレクションと相性が良いものの1つがasync/await

    • Rustでのasync/await利用は、メモリ管理と組み合わさることで問題を引き起こす

  • RCUの動機付けの後に、一般的なガベージコレクションの議論へ移るのはやや意外

  • ソフトウェア開発では2つのケースを考える

    • ホットパスではカスタムアロケータを使い、それ以外ではガベージコレクションが便利

  • RCUから一般的なトレーシングガベージコレクションへの移行は巧妙な戦略に見える

    • 手動メモリ管理は単なるmalloc/free呼び出し以上のものを含む

  • システムプログラマーにとって、いつガベージコレクト可能かを識別するのは難しい

  • RustとC++のライフタイム管理ツールはメモリ解放の自動化には役立つが、複雑さ自体を単純化はしない