- 高性能メモリアロケータ jemalloc は、Metaのソフトウェアスタックにおいて Linuxカーネルやコンパイラと並ぶ中核インフラとして機能してきた基盤コンポーネント
- ここ数年、jemalloc 開発を導いてきた中核的なエンジニアリング原則から徐々に逸脱したことで、技術的負債 が蓄積し、進捗が鈍化
- コミュニティのフィードバックを受け止め、プロジェクト創設者 Jason Evans を含むメンバーとの議論を経て、元のオープンソースリポジトリが再アクティブ化（unarchived）
- 今後は技術的負債の整理、Huge-Page アロケータ の改善、メモリ効率の向上、AArch64 最適化などに注力する計画
- Meta は jemalloc の 長期的なスチュワードシップ を改めて確認し、コミュニティとの協力を通じてプロジェクトを発展させる方向へ転換
jemallocの位置づけと重要性
- jemalloc は 高性能メモリアロケータ として、Meta のソフトウェアスタックで一貫して高いレバレッジを提供してきたコンポーネント
- ハードウェアの変化や上位レイヤーソフトウェアの変化に合わせて継続的に適応してきており、Linuxカーネルとコンパイラ とともに Meta インフラの安定性と性能に貢献
原則からの逸脱と反省
- 基盤ソフトウェアコンポーネントには、実用性と原則の間で 最高水準の厳格さ が求められる
- jemalloc がもたらす高いレバレッジゆえに短期的な利益を取りにいく誘惑が存在し、それを退けるには組織レベルの 強い自己規律 が必要
- ここ数年、jemalloc 開発を導いてきた中核的なエンジニアリング原則から 段階的な逸脱 が起きていた
- 一部の決定は即時の利点をもたらしたが、その結果生じた 技術的負債が進行を妨げた
- コミュニティのフィードバックを真摯に受け止め、プロジェクト創設者 Jason Evans を含むコミュニティメンバーとの対話を実施
- スチュワードシップが jemalloc の長期的な健全性に与えた影響を深く省察し、アプローチの変更を共有
- 技術的負債の解消と、jemalloc のための 長期ロードマップ再構築 に着手
新たな章: リポジトリのアーカイブ解除と今後の計画
- コミュニティとの対話の結果、元の jemalloc オープンソースリポジトリが再アクティブ化（unarchived） された
- Meta はプロジェクトのスチュワード役を継続できるようになり、保守負担の軽減とコードベースのモダナイズに注力する方針
- 技術的負債の整理: リファクタリングと改善を通じて、すべてのユーザーにとって効率的で信頼でき、使いやすい状態を維持
- Huge-Page アロケータ（HPA）: Transparent Hugepages（THP）をより有効活用し、CPU 効率を向上
- メモリ効率: パッキング、キャッシュ、パージのメカニズム改善による メモリ効率の最適化
- AArch64 最適化: ARM64 プラットフォームでデフォルト状態でも良好な性能を確保
コミュニティとの協力強化
- Meta は 行動による信頼構築 を重視し、jemalloc の健全な発展を目指す
- コミュニティの フィードバックと参加を歓迎 し、ともに jemalloc の未来を築いていくことを期待
- オープンソースエコシステムの中で 持続可能な協力と発展 を推進していく
1件のコメント
Hacker Newsの意見
Facebook在籍時、jemallocのpurgingメカニズムを改善するためにカーネルパッチを保守していた
カーネルやセキュリティコミュニティでは不評だったが、ベンチマークでは効率が高かった
問題は、メモリを別スレッドに再割り当てするとzeroingが発生し、キャッシュ局所性や性能に影響する点だった
同じセキュリティドメイン内でメモリを再利用する場合は不要な動作だったが、「セキュリティドメイン」をどこまでと定義するかについて合意が難しかった
関連する議論はLinux Kernelメーリングリストにある
HHVMでそのパッチ適用前後に広範なベンチマークを行ったが、システムレベルでは統計的に有意な差はなかった
一部のマイクロベンチマークでは改善があったかもしれないが、システム全体の性能には影響がなかったためカーネルから外された
最近MicrosoftのmimallocをLD_PRELOADで使って1GBのhuge pageを活用した
メモリ集約的なプログラムで約20%の性能向上が得られた
LinuxでオープンソースのMSライブラリを使って性能を上げるのは妙な気分だ
malloc周りにはもっと競争が必要だと感じる
Rustで書かれたアプリで、ほとんどは静的リンクだった
たとえばapp1ではglibc比でtcmallocがRSSを35%削減し、処理時間を30%短縮した
全体の結果はtcmallocリポジトリを基準にテストしたものだった
Turbo Pascalですらメモリアロケータを直接定義できるAPIを提供していた
結局のところ、「one size fits all」型のアプローチには昔から限界があった
リクエストごとにプールを作り、リクエストが終わると全体を一度に解放する構造だった
mallocにもこういう方向に進化する余地は多いと思う
割り当てパターンが単純ならサードパーティ製mallocより良い結果を得られることもある
mallocは魔法のようなブラックボックスに見られがちだが、実際にはそこまで優れているわけではない
私たちのチームは2年前にglibc mallocからjemallocへ移行した
Pythonサービスでメモリ使用量が15〜20%減った
ただしコンテナ環境ではoversize_thresholdの調整が重要だった — 設定を誤るとOOMが発生する
長時間稼働するサービスでjemallocとmimallocを比較したベンチマークがあるのか気になる
関連する参考記事としてJemalloc Postmortemと
Jemalloc Repositories Are Archivedを勧める
もしかすると今回の変化は世界的なメモリ不足が背景にあるのだろうか
「メモリアロケータの入れ替えで年間数百万ドル削減」のような計算も出てきそうだ
0.1%の効率向上だけでも月10万ドルの節約が可能だった
主な削減要因は冷却費用(HVAC)とサーバー購入数の減少だった
今はメモリ削減も大きなテーマだが、当時はそうではなかった
数千台のサーバーに影響するなら小さな改善も大きな数字になる
こうした定量的改善の文化が根付いている
10%速くなるだけでもLLM競争で優位に立てる可能性がある
性能改善のインセンティブは非常に大きい
オーストラリアで低レベルプログラミングをしていたが、整理解雇に遭った
こういう問題を解くのが本当に好きだが、現地市場は大半がReact CRUD中心で残念だ
World Bank資金で進められたスタートアッププロジェクトでRuby + jemallocを本番環境に導入した
速度とメモリ効率が目に見えて改善し、AWSコストを大幅に削減できた
8年前の話だが、なぜいまだにjemallocが標準として定着していないのか不思議だ
すでに運用中のシステムを変えるのは、利益が明確でも簡単ではない
jemallocを使ってメモリリークの原因を追跡した事例もある
GOV.UK技術ブログの記事を参照
Metaが自社フォークで作業していた内容を大規模にマージした
PR #2863で確認できる
jemallocのタイムラインや歴史がまとまった資料はあるのだろうか
オープンソースプロジェクトなのに、なぜMetaが主導権を握っているのか気になる
Jemalloc Postmortemブログを参照
残り2人も非公開でMeta所属の可能性がある