Addressing Fragmentation in ZGC through Custom Allocators

原文はこちら。
The original article was written by Joel Sikström (M.Sc. Computer and Information Engineering).
https://inside.java/2024/06/19/thesis-zgc-fragmentation/

この記事で記載している成果は、Oracle、Uppsala大学、KTHによる共同研究の一環によるものです。ストックホルムのOracle DevelopmentオフィスでのJVM研究について詳細を知りたい方は、inside.javaのブログをフォローしてください。

Oracle, Uppsala University, and KTH in joint JVM research projects
https://inside.java/2020/06/12/joint-research-projects/


Summary

Uppsala大学でコンピュータおよび情報工学の5年制学位を取得中のJoel Sikströmです。ソフトウェアエンジニアリングを専攻しています。

このエントリでは、2024年春にOracleのストックホルムオフィスのGCチームの一員として取り組んだ修士論文について詳しく説明します。この春Oracleで私と同じ分野で修士論文を執筆してきたCasper NorrbinとNiclas Gärdsと密接に協力してきました。

Problem Statement

ZGCやその他のガベージコレクタは通常、バンプポインタアロケーション(bump-pointer allocation)を使います。この方法は連続した割り当てには効率的ですが、時間の経過とともにフラグメンテーションを引き起こす可能性があります。フラグメンテーションは、再利用が難しいメモリのギャップが生じると発生し、高コストな稼働中オブジェクトの再配置が必要になります。この研究は、バンプポインタアロケーションと並行してフリーリストベースのアロケータを使って、ZGCにおける再配置の必要性を減らすことを目的としています。これにより、特定のシナリオにおいて断片化したメモリをより効率的に追跡、利用できるようになります。

Methodology

この研究では、Miguel MasmanoらによるTLSF (Two-Level Segregated Fit) アロケータをベースに、ZGCでの使用に適したアロケータに改良することに焦点を当てています。

TLSF: a new dynamic memory allocator for real-time systems
https://ieeexplore.ieee.org/document/1311009

主な改良点は以下の通りです。

0-byte Header

ZGC内の情報を利用して、アロケータは0バイトヘッダを導入し、内部の断片化を大幅に減らす。下図は、

  1. リファレンス・デザイン
  2. 一般的なデザイン
  3. 最適化された0バイト・ヘッダー

をそれぞれ示している。

Block Header Comparison
ZGC Small Pages

ZGCの限られたサイズ(2MB)ならびにアロケーション・サイズ範囲([16 B, 256 KB])内で使われるようアロケータを制限することで、内部表現をより効率的に格納、使用できる。下図は、大量の第1レベルと第2レベルをどのように64ビット・ワードに平坦化するさまを示している。

Bitmap Flattening

Concurrency

様々な問題やユースケースを考慮して、ロックフリー・メカニズムを使ってアロケータに対する並行操作をサポートしている。

0バイトヘッダは、アロケータへの一連の小さな適応により可能になったので、特に注目に値します。結合を延期したり、サポートされるヒープ・サイズをZGCのスモール・ページのサイズに縮小したり、Java Objectヘッダーのすでに一部である情報の活用したりといった適応により、0バイト・ヘッダーが可能になっています。さらに、並行処理は多くの方法で解決できますが、私の研究の一部であるロックフリーのソリューションは、これまでの適応によって実装が大幅に容易になります。これらの適応がなければ、ロックフリーのソリューションの実装はもっと複雑になっていたことでしょう。

Results

適応済みのアロケータは、メモリの割り当てに重点を置き、ZGCで使用できる有望な可能性を示しています。

Performance

単一のアロケーションでは、新しいアロケータはリファレンス実装と同等のパフォーマンスを示したが、単一のデアロケーションや実際のアロケーション・パターンでは若干遅くなった。このトレードオフは、フラグメンテーションの大幅な削減を考えると、許容範囲と考えられる。

Memory Efficiency

0バイトヘッダの導入とその他の最適化により、内部フラグメンテーションが顕著に減少した。このメモリ効率の向上は、新しいアロケータが断片化したメモリを効果的に管理できることを示唆している。

Conclusion

この研究が示しているのは、ZGCのようなガベージ・コレクタで使用するためにアロケータをカスタマイズすることが、メモリの断片化に対処するための実行可能なアプローチである、ということです。適応済みのアロケータによって、コストのかかる再配置の必要性が減るだけでなく、全体的なメモリ効率も向上します。ZGCでの利用のためにTLSFを適応させる大きな可能性があることを示しましたが、これは他のアロケータにも適用できる可能性があります。今回の研究の最も明白な次のステップは、このアロケータのZGCへの統合です(これは、私と並行してOracleで論文を書いたNiclas Gärdsが行いました)。他にも、LilliputプロジェクトによるJavaの新しい最小アロケーションサイズや、適応済みアロケータの並行処理実装におけるスターベーションへの対処などを検討する必要があります。

Project Lilliput
https://wiki.openjdk.org/display/lilliput/Main

知識を共有してくださり、チームの一員として受け入れてくださり、学習意欲を刺激する環境を育ててくれたストックホルムのOracleオフィスの皆様に心から感謝して、終わりにしたいと思います。Erik ÖsterlundとTobias Wrigstadには、プロジェクト全体を通して安定したサポート、知識、指導をいただきました。どうもありがとうございました。最後に、この春を特別でエキサイティングなものにしてくれたCasper NorrbinとNiclas Gärdsに感謝します!

今回の研究成果の詳細を知りたい方は、DiVAで発表したレポートをご覧ください。この記事で説明したコンセプトについて、より詳細かつ深い内容と、この記事でカバーしきれなかった領域が含まれています。

Addressing Fragmentation in ZGC through Custom Allocators: Leveraging a Lean, Mean, Free-List Machine
https://uu.diva-portal.org/smash/record.jsf?pid=diva2%3A1867414&dswid=-8707

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください