博士

ロボ子、jemallocって知ってるか？ 20年近く公開されてきたメモリ割り当てツールなんじゃ。

ロボ子

はい、博士。Lykenプログラミング言語のために開発が始まったものですよね。でも、活発な開発は終了したとのことですが…。

博士

そうなんじゃ。元々はLykenのアロケータとして開発が始まったんじゃが、FreeBSDに統合されたり、Mozilla Firefoxでも使われたり、色々あったんじゃな。

ロボ子

FreeBSDへの統合後、スレッドごとのガベージコレクションをトリガーするメカニズムが不足していたんですね。当時はマルチプロセッサコンピュータへの移行期で、並列スレッド実行に対応できるアロケータが求められていた、と。

博士

そうそう。FreeBSDにはphkmallocってのがあったんじゃが、並列処理には弱かったんじゃ。そこで、スケーラビリティの高いjemallocが採用されたんじゃな。

ロボ子

しかし、一部の負荷で断片化の問題が発生したんですね。統一されたエクステント割り当てアプローチが原因だった、と。

博士

そうなんじゃ。サイズクラスの分離がないのが問題だったんじゃな。それで、MozillaがFirefox 3で高断片化に悩まされて、jemallocとの協力が始まったんじゃ。

ロボ子

Windowsへの移植は大変だったようですね。FreeBSDのlibcライブラリからフォークして、移植コードを追加した、と。

博士

そうなんじゃ。Mozillaの開発者がアップストリーム版への移行を試みたんじゃが、ベンチマークではフォーク版が優れてたみたいじゃな。

ロボ子

Facebookに入社後、インストルメンテーションが課題になったんですね。メモリリークのデバッグにtcmallocやgperftoolsのpprofヒーププロファイリングツールが必要だった、と。

博士

そうなんじゃ。そこで、jemalloc 1.0.0でpprof互換のヒーププロファイリング機能が追加されたんじゃ。Facebookでは、jemallocチームが主要なパフォーマンス改善とか、色々やったみたいじゃな。

ロボ子

Facebookのリブランド後、コアテクノロジーへの投資が減り、jemallocの開発を管理する担当者がいなくなったんですね。それで、アップストリームの開発が終了した、と。

博士

そういうことなんじゃ。Valgrindの削除とか、色々あったみたいじゃが、根本的な問題は外部の利用とニーズに対する認識の欠如だったんじゃな。

ロボ子

MozillaのMike Hommey氏によるFirefoxのアップストリームjemallocへの移行も、ほぼ成功しかけたんですね。CMakeベースのビルドシステムへの移行は停滞してしまったようですが。

博士

そうなんじゃ。25年以上にわたって手動メモリ管理よりもガベージコレクションを強く支持してきたから、今回の件は異例の転換だったんじゃな。

ロボ子

博士、jemallocの歴史は、メモリ管理の進化と、組織の変化が技術に与える影響を示していますね。

博士

まさにそうなんじゃ！ しかし、ロボ子よ、メモリ管理といえば… 私の部屋もメモリ不足で、片付けなきゃいけないんじゃ！

ロボ子

博士、それはメモリ管理ではなく、単なる整理整頓です…。