ハクソク

世界を動かす技術を、日本語で。

Jemalloc ポストモーテム

2025年6月13日原文(jasone.github.io)

概要

jemalloc は2004年に構想され、20年間にわたり公開利用されたメモリアロケータ。 開発フェーズ ごとに成功と課題を経験し、主にFreeBSD、Firefox、Facebook/Metaで進化。 オープンソース として公開は継続するが、上流開発は終了。 外部との連携やニーズ把握の難しさ、技術的負債が課題として浮上。 今後はフォークや新たな開発者による進展に期待。

jemallocの開発フェーズと回顧

  • Phase 0: Lyken

    • 2004年、科学計算向け言語Lykenの開発とともに 手動メモリアロケータ を実装
    • 2005年5月、機能的に完成
    • ガーベジコレクタは未完成
    • 2005年9月、 FreeBSD への統合を開始
    • Lykenからアロケータを削除し、システムアロケータの薄いラッパーに移行
    • Lykenで必要だった 統計機能 は後年jemallocに実装

  • Phase 1: FreeBSD

    • 2005年、マルチプロセッサ化の進展を背景に phkmalloc からの置換を目指す
    • 初期統合後、 断片化問題 が顕在化（特にKDEアプリで深刻）
    • 原因は サイズクラス分離 の欠如による統一的な割り当て方式
    • 研究と実験を経て、 サイズ分離型レイアウト に全面刷新（2006年BSDCan論文で解説）

  • Phase 1.5: Firefox

    • 2007年、 Mozilla Firefox 3 のリリース前、断片化問題が深刻化
    • Linux移植は容易だったが、 Windows対応 は困難
    • FreeBSD libcにあったjemallocを フォーク し、移植性向上
    • 実装が単一ファイルで管理しやすかったが、 複雑化 が進行
    • Firefox開発者が上流に貢献するも、 フォーク版の方が高性能 という結果に
    • 最適化の行き過ぎか、性能退化かは不明

  • Phase 2: Facebook

    • 2009年、Facebookでの 導入障壁は計測機能の不足
    • tcmallocやpprof によるヒーププロファイリングが必須
    • jemalloc 1.0.0で pprof互換ヒーププロファイリング を実装
    • GitHubへ移行し、外部貢献も増加
    • 3.0.0で テスト基盤とValgrind対応、4.xで データ削除の最適化とJSONテレメトリ、5.xで extents化 や 巨大ページ対応
    • 5.0.0で Valgrind対応を削除、Facebook内で不要と判断
    • Rust開発者などから反発、 Rustバイナリからの除外 が加速
    • Facebookの 大規模テレメトリ が性能改善に大きく寄与
    • 継続的インテグレーションや包括的テレメトリも整備
    • 2017年以降、Qi Wangらが開発・保守を継続
    • Metaへの社名変更以降、 コア技術への投資減少、HPA（Huge Page Allocation）の停滞

  • Phase 4: Stasis（停滞期）

    • 上流開発の終了 を宣言
    • Metaと外部のニーズ乖離、Meta独自方針へ
    • 技術的負債の返済には膨大なリファクタリングが必要
    • devブランチや5.3.0リリースからの フォーク に期待
    • Valgrind対応削除 など、外部利用者への認識不足が問題に
    • Androidでの利用や置換にも当初気付かず
    • 他組織からの 主要貢献者確保に失敗
    • CMake対応なども未完
    • オープンな開発体制 だけでは独立プロジェクトとしての発展は困難

jemallocの総括と今後

  • ガーベジコレクション 推進派でありながら、手動メモリアロケータ開発に大きな満足感
  • 協力者・利用者・支援者 への感謝
  • 今後は 新たな開発者やフォーク による発展に期待
  • オープンソースとしての公開 は今後も継続

開発フェーズ別の成功・失敗まとめ

  • 成功例

    • FreeBSDやFacebookなど大規模基盤での採用
    • 高性能・低断片化・豊富なテレメトリ
    • 外部貢献による機能拡張

  • 失敗例

    • 断片化問題やValgrind対応削除による反発
    • 外部利用者や他プロジェクトのニーズ把握不足
    • 他組織との主要貢献者ネットワーク形成に失敗
    • 技術的負債の蓄積と停滞

今後の展望

  • 既存の5.3.0リリースやdevブランチ からのフォークによる新展開
  • 他組織やコミュニティ主導での 独自発展
  • メモリアロケータ分野 での新たな挑戦と進化

Hackerたちの意見

素晴らしい成果と未来におめでとう！jemallocは多くのメモリアロケーターにとってインスピレーションだったね。

└

jemallocが登場した頃、FreeBSDを使ってたんだけど、そのlibcの一部を入れ替えることを想像するだけで驚いたよ。正直、そんなこと考えたこともなかったし、他に何を一気に置き換えられるか考えさせられた。

へぇ、面白いね。jemallocはredisをはじめ、いろんなプロジェクトで使われてるメモリアロケーターなんだ。もしアロケーターを変えなきゃいけなくなったら、パフォーマンスにどんな影響が出るんだろう？

└

なんで変えなきゃいけないの？ソフトウェア開発って、時には「もう終わった」って感じになることもあるし、ライブラリにあんまり手を加える必要がないこともあるよね。

└

Firefoxもそうだね。

ダグ・リアが再び火を灯して、現代版のマルチスレッドdlmalloc2を作ったらめっちゃクールだよね！

└

dlは今、オープンJDKのガバナンスボードでただの観察者だから、時間はあるかもね。

最近、サービスが数日ごとにOOMになるメモリ断片化の問題を解決するためにjemallocを使ったんだ。今のjemallocはそのまま使えるけど、将来的にはどのアロケーターを選ぶべきか悩んでる。tcmallocや、標準のglibcよりもパフォーマンスが良いことを目指している他のアロケーターについて、経験がある人いる？

└

snmalloc

└

mimallocはいい選択だね。CPythonも最近mimallocに切り替えたし。

└

mimallocを試してみて。mimallocの上に機能をプロトタイプしたことがあるけど、努力が無駄になったものの、コードは（2020年頃の話）きれいに書かれてて、よくメンテナンスされてたし、ハッキングするのが楽しかった。jemallocをシステムでmimallocに入れ替えた時、断片化の成長制御やヒープ使用の観点では同等かそれ以上だったよ。

jemalloc以外に、macOSのmalloc/freeをLinuxのLD_PRELOADみたいにシームレスに上書きできるアロケーターはないと思う（少なくとも2020年頃まではね）。jemallocはすごくいいゾーンベースの方法でデフォルトに設定できるし、Appleの変わったアロケーターの要件にも対応できてるから、他のサードパーティのアロケーターがmalloc/freeを上書きしようとしたときに躓くことがないんだよね。

Hacker Newsで議論の続きを見る