ハクソク

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

Metaのjemallocへの再コミットメント

2026年3月17日原文(engineering.fb.com)

概要

  • Metaは jemalloc の長期的な利点を再評価
  • コードベースの近代化とメンテナンス負荷の削減に注力
  • オープンソースコミュニティとの協力を重視
  • 技術的負債の解消と今後のロードマップ策定
  • 主要な改善分野への取り組みを計画

Metaによるjemallocへの新たな取り組み

  • jemalloc はMetaのソフトウェアインフラにおいて 基盤的役割 を果たす高性能メモリアロケータ
  • Linuxカーネルやコンパイラと並び、 信頼性 ・ パフォーマンス に長期的な貢献
  • 基盤ソフトウェアは 高い厳格さ と 原則的なエンジニアリング が要求される
  • 短期的な利益を追求した結果、 技術的負債 が蓄積し進捗が鈍化
  • コミュニティからの フィードバック を受け、開発方針を再評価
  • プロジェクト創設者 Jason Evans を含むコミュニティと対話し、今後の方向性を共有
  • 技術的負債の解消 と 長期的なロードマップ の再構築を開始

jemallocの新章

  • オリジナルリポジトリ （https://github.com/jemalloc/jemalloc）を アーカイブ解除
  • Metaは メンテナンス負荷の削減 と コードベースの近代化 を推進
  • 最新および新興ハードウェア・ワークロードへの適応を継続
  • 今後の主な改善分野
    • 技術的負債の削減
      • コードのクリーンアップ、リファクタリング、ユーザーにとっての使いやすさ・信頼性・効率性の向上
    • Huge-Page Allocator（HPA）の改善
      • Transparent Hugepages（THP） の活用強化によるCPU効率の向上
    • メモリ効率の改善
      • パッキング、キャッシング、パージ機構の最適化
    • AArch64（ARM64）最適化
      • ARM64プラットフォームでの 即時パフォーマンス 向上

コミュニティとの協力と今後

  • 信頼 は行動で築かれるとの認識
  • jemallocの 健全性 と 進歩 によってコミットメントを示す方針
  • コミュニティからの フィードバック や コラボレーション を歓迎
  • jemallocの未来 を共に形作るための参加呼びかけ

参考リンク

Hackerたちの意見

最近、メモリを多く使うプログラムで巨大（1GB）ページをうまく使うために、Microsoftのmimallocを使い始めたんだ（LD_PRELOAD経由で）。パフォーマンスの向上はかなり大きくて、約20%も上がったよ。LinuxシステムでオープンソースのMSライブラリを使うのはちょっと変な感じだけど、mallocの世界にはもっと競争が必要だと思う。さまざまな巨大ページサイズや透過的巨大ページを考えると、デフォルトのGNU libcよりも得られる利点はたくさんあるよね。

└

GC言語の一番いいところは、メモリの割り当てや解放がすごく効率的になることだよね。コストがまとめられているから、プロファイルにもはっきり現れるし。

└

Dr DobbsやC/C++ユーザーズジャーナル、BYTEのデジタルアーカイブに行くと、特別にケース分けされたメモリアロケータを持つ会社の広告があるよ。MS-DOS用のTurbo Pascalみたいなツールチェーンでも、メモリアロケータをカスタマイズするためのAPIがあったし、全てに合う一つの解決策なんてなかったんだよね。

└

jemallocを10年以上使ってるけど、アップデートする必要はあまり感じないな。新しいmallocが出ても、ベンチマークではいつも良い結果を出してるし。最後にmimallocをチェックしたのはかなり前、たぶん5年前だけど、明らかに劣ってたし、GitHubのイシューでも同意する人が多かったから、もう見なくなっちゃった。

└

ちょっと気になるんだけど、Xeonか他のプラットフォームで1GBの巨大ページを使ってるの？このクラスのページは、確かTLBスロットが1つしかないから、利用するのが一番難しいと思ってたんだけど。

└

本当に変わるべきなのは、malloc/reallocだけじゃなくて、もっと表現力のあるメモリ割り当てインターフェースが必要だと思う。プログラムが何をしようとしているのか、もっと情報があれば、メモリアロケータはかなり良い仕事ができるはずだよ。

└

zenlispをOpenBSDで動かすためにmimallocを使ったんだけど、ベースのパラノイドmallocとぶつかっちゃうからね。

└

多くの場合、mallocを使うよりも良い方法があるよ。例えば、巨大なページが必要だとわかっているなら、mmapで直接巨大なページをマップすればいい。もし任意のalloc/freeを使いたいなら、サードパーティのmallocを使うのがいいよ。alloc/freeのパターンが任意でないなら、もっと良い結果が出せる。mallocは魔法のブラックボックスみたいに扱われてるけど、実際はあんまり良くないんだよね。

└

いくつかのLinuxアプリのためにいくつかのアロケーターを評価した結果、(現代の) tcmallocが時間とスペースの面で一貫して勝ってることがわかった。私たちのアプリは主にRustで書かれていて、アロケーターは静的にリンクされてた（glibcを除いて）。残念ながら、アロケーションパターンについてあまり文脈をキャッチできなかったけど、一般的にアプリはほとんどのRustアプリよりも高いレートでアロケートとデアロケートしてると思う（少なくとも私が望むよりも）。2025年7月の結果はこんな感じ：行は、app1: glibc: 215,580 KB, 133 ms mimalloc 2.1.7: 144,092 KB, 91 ms mimalloc 2.2.4: 173,240 KB, 280 ms tcmalloc: 138,496 KB, 96 ms jemalloc: 147,408 KB, 92 ms app2, bench1 glibc: 1,165,000 KB, 1.4 s mimalloc 2.1.7: 1,072,000 KB, 5.1 s mimalloc 2.2.4: tcmalloc: 1,023,000 KB, 530 ms app2, bench2 glibc: 1,190,224 KB, 1.5 s mimalloc 2.1.7: 1,128,328 KB, 5.3 s mimalloc 2.2.4: 1,657,600 KB, 3.7 s tcmalloc: 1,045,968 KB, 640 ms jemalloc: 1,210,000 KB, 1.1 s app3 glibc: 284,616 KB, 440 ms mimalloc 2.1.7: 246,216 KB, 250 ms mimalloc 2.2.4: 325,184 KB, 290 ms tcmalloc: 178,688 KB, 200 ms jemalloc: 264,688 KB, 230 ms tcmallocはgithub.com/google/tcmalloc/tree/24b3f29からのもの。どのjemallocがテストされたかは覚えてない。

└

ウェブサービスの初期の頃、apache portable runtimeを使って、特にメモリプールを利用していたのを思い出す。ウェブリクエストが来ると、そのためにメモリプールを割り当てて、そこからすべてのメモリ割り当てを行うんだ。そして、ウェブリクエストが終わるときには、きれいに終わるか、いろんなエラーが出るかに関わらず、そのプール全体を解放するだけで済む。すごく便利で、印象に残ったな。mallocもいろいろ面白い成長や変化があると思うよ。

└

オペレーティングシステムの改善があれば、もっと多くの人が巨大ページを使う気になると思うな。特に、Linuxでは壊れにくくして、Windowsでは管理者権限がなくても使えるようにしてほしい。問題の一番の要因は、どちらのOSも2MBのページをスワップできないことなんだよね。だから、誰かがそれを直すことに気を使う必要がある。

関連情報。他にも？ Jemallocのポストモーテム - https://news.ycombinator.com/item?id=44264958 - 2025年6月（233件のコメント） Jemallocリポジトリはアーカイブ済み - https://news.ycombinator.com/item?id=44161128 - 2025年6月（7件のコメント）

Hacker Newsで議論の続きを見る