ディスカッション (11件)
Meta(旧Facebook)が、高性能な汎用メモリアロケータである「jemalloc」の開発に、改めて注力することを発表しました。大規模インフラのメモリ効率を支えるこの重要プロジェクトの今後に注目が集まっています。GitHubリポジトリ:https://github.com/jemalloc/jemalloc
最近、Microsoftのmimallocを(LD_PRELOAD経由で)使い始めて、メモリ消費の激しいプログラムで1GBのヒュージページをうまく活用できるようにしたんだけど、パフォーマンスがかなり上がった(20%くらい)。Linuxシステムでパフォーマンスを出すためにMSのオープンソースライブラリを使ってるのは、なんだか妙な気分だけどね。malloc界隈はもっと競争が必要だよ。色々なサイズのヒュージページやTransparent Huge Pagesがある中で、デフォルトのGNU libcから得られるもの以上に、もっと大きなメリットが得られるはずなんだ。
関連。他にもある? Jemalloc事後分析 - https://news.ycombinator.com/item?id=44264958 (https://news.ycombinator.com/item?id=44264958) - 2025年6月 (コメント233件) Jemallocリポジトリがアーカイブ化 - https://news.ycombinator.com/item?id=44161128 (https://news.ycombinator.com/item?id=44161128) - 2025年6月 (コメント7件)
これって世界的なメモリ不足のせいなのかなって勘ぐっちゃうよね。「お、メモリアロケータを効率的なやつに変えれば、来年までに数千万ドルの節約になるぞ」みたいな感じで。
これに関する簡潔なタイムラインか経緯ってどこかにある?jemallocは100%オープンソースだと思ってたんだけど、なんでMetaが管理してるの?
昔、世界銀行が資金提供してたスタートアップでシニアリードエンジニアをやってた時、本番環境のRubyにjemallocを導入したのを覚えてるよ。速度もメモリ効率も目に見えて良くなったんだ。普通のRubyを使うのと比べて、AWSのコストを大幅に削減できた。8年も前の話なのに、なんで他のプロジェクトでもデファクトとして採用されてないんだろうね。
「パージ機構の改善を予定している」か...。Facebookにいた頃、jemallocのパージ機構を改善するためにカーネルパッチをいくつかメンテナンスしてたよ。カーネル界隈やセキュリティコミュニティには不評だったけど、ベンチマーク上は確実に効率が上がってた。多くのプログラムはマルチスレッドで動いてて、あるスレッドで確保して別のスレッドで解放したりする。Jemallocの主な仕組みは、madviseでページをカーネルに戻して、それを別のスレッドのプールで再割り当てさせることだったんだ。問題が一つあって、これにはメモリのゼロクリアが伴うから、キャッシュの局所性やアプリ全体のパフォーマンスに影響が出るんだよね。同じセキュリティドメイン内でページを再利用するなら、ゼロクリアは全く不要なんだけど。問題は、たとえオプトイン方式だったとしても、その『セキュリティドメイン』が何かってことに全員の合意を取り付けるのが難しかったことかな。 https://marc.info/?l=linux-kernel&m=132691299630179&w=2 (https://marc.info/?l=linux-kernel&m=132691299630179&w=2)
自分たちのフォークで進めてた開発内容を、いきなり巨大なマージとしてぶっ込んできたね。強烈なスタートだ:https://github.com/jemalloc/jemalloc/pull/2863 (https://github.com/jemalloc/jemalloc/pull/2863)
世界的なメモリ供給ショックについての言及がないのが意外だな。自分の(まだ比較的若い)キャリアの中で、経済状況がソフトウェアの優先順位をメモリアロケーションの方へと向かわせたのは初めてだから、そのあたりの変化をもっと詳しく知りたいな。
こういう低レイヤのプログラミングを含む仕事をしてて、最近リストラされたオーストラリア人としては...こういう類の挑戦に取り組むのは大好きなんだけどさ。悲しいことに、オーストラリアの求人市場はほとんどがReactのCRUDアプリばっかりで、自分のニッチなスキル(かつ趣味でもあるんだけど)を活かせる仕事は見つかりそうにないんだよね。