Rustの「Allocator」APIがついに安定版へ！メモリ管理の次なる一手

まだマージされてないよね。どれくらい時間がかかるか分かってる人いる？

説明によると、最近のRust All Handsでlibsチームの対面会議で議論されて、関係者の間で大筋で合意が取れてるみたいだよ。この土壇場で大きな反対がなければ、早ければ火曜の次回のlibsチーム会議でFinal Comment Period（最終コメント期間）として承認されるかも。そうなれば、ブロックするような懸念を挙げるための猶予期間がさらに10日間できるはず。

PRにリンクされているhackmd.io を見てみて。Existing-points-of-contention（既存の論点）セクションの最後の項目にその件について書かれているよ。

おー、なるほど！ありがとう！

その場にいたけど、将来的に何らかのストレージの形を望んでいるもう一人の主要な声が私だよ。supertrait item shadowingとsupertrait auto-implsさえあれば、storage APIはAllocatorの安定化と完全に後方互換性があるって再確認できた。ライブラリ側も他の多くの理由でこれを求めているしね。それに、storage APIが許容するオプションを全部盛り込むと、結果的にAllocatorとほぼ同じAPIになる。このトレイトは実質「PinningMultiStorage」のようなものだと考えていいよ。

OS開発をサポートするフォールダブル（失敗しうる）アロケータってこと？

仕事でこれを使う予定だよ。グローバルアロケータを特定のカウント用アロケータでラップして、メモリがどれだけ確保・解放されたかをバイト単位で集計することで、各機能がどれだけメモリを消費しているかを確認するのに役立てるつもり。

システムヒープのアロケータ以外を使えるっていうのは、多くのアプリケーションにとってめちゃくちゃ重要な機能だよ。Rustではグローバルにカスタムアロケータを設定できるけど、実際にはアロケータの種類ってその場のコンテキストに依存することが多いよね。現状のStableなRustだと、bumpaloみたいなライブラリを使わない限りそれができなくて、結局Vec API全体を複製して非標準のメモリ確保に対応するみたいな面倒なことをしなきゃいけないんだ。

Allocatorはcoreで定義されているから、グローバルアロケータを全く定義せずに（allocやstdにリンクせずに）ヒープ確保を使いやすくできる道が開けるんだよ。BoxやVecのようなアロケートを行うADTをcoreに移動できる可能性が出てきたってこと。

メモリ割り当てって万能なやり方なんてないからね。それぞれメリット・デメリットがある選択肢がたくさんあるし。

フリーリストアロケータは一番汎用的だね（実際、ほとんどのシステムでmallocはフリーリストアロケータを使ってる）。でも低速なんだよ。割り当てるたびに、システムは適切な空きメモリが見つかるまで全領域のリストをチェックしないといけないから。それに、特に小さいアドレス空間だとヒープの断片化も起きやすい。

だからAllocatorトレイトを使えば、もっと細かいレベルでアロケータを選べるようになるんだ。例えば、プログラムの中で一括解放できるような割り当てを大量に行う場所があるなら、バンプアロケータを使うとかね。あるいは似たようなレイアウトの割り当てがたくさんあるなら、スラブアロケータにまとめるといった具合に。

まあ、hashbrownは次のバージョンアップでstdのAllocatorに切り替えてくるんじゃないかな。

本当にその通り。allocator_api2はずっとnightlyトレイトのミラーでしかなかったから、hashbrownにとってはポートというより機能フラグを切り替えるようなものだよね。

なんでそんなClaudeみたいな書き方でRedditのコメントしてるの？

AIがRedditのコメントを学習データにしてるからね...

なんで低評価ついてるのか分からん。めちゃくちゃ分かりやすい説明なのに。

うん、Claudeって「genuinely」「explicit about...」「actually fixes」「a real gap」みたいな表現を使いすぎる傾向あるよね。

つまりこれ、将来的に後方互換性を保ったまま実現できるってことだよね？

なんでそんなに怒ってるのかよく分からないな。彼らは将来的に追加できるって明確に言ってるわけだし、デアロケータトレイトまわりの議論や不明点だけで今回の進歩を止めるべきじゃないでしょ：

Deallocatorトレイトを分離する
trait Allocator: Deallocator {...}
特定のケース（例えばバンプアロケータ）では、割り当てよりも解放の方が情報が少なくて済むし、なんなら何もしなくていい（no-op）場合もある
APIの複雑性が少し増すし、2つのトレイトを実装しなきゃいけないのはエルゴノミクス的にちょっと残念
別案として、とりあえず今のままAllocatorを安定化させて、詳細は後回しにするのもアリ（GitHubのコメント参照）
将来的にsupertraitの自動実装でより綺麗にできるはずだし、後から切り替えても破壊的変更にはならないはず
おそらくCollection<T, A: Allocator>をA: Deallocatorに緩和する方法について、APIのbikeshedding（些末な議論）がたくさん必要になるだろうけど
https://github.com/rust-lang/libs-team/issues/769