静的割り当てと一定の作業：メモリ安全性の死角を回避する
Static Allocation, Constant Work
この記事では、メモリ安全性の難しい問題に対する実践的な解決策を探ります。著者は、型なしのアロケータが引き起こす型混乱を避けるために、型分離プールを使用する方法を提案します。さらに、動的割り当てを排除する静的割り当てと、常に一定の作業量を保証する「一定の作業」の原則を紹介します。これらの手法は、TigerBeetleのコードベースで実際に適用されており、パフォーマンスの予測可能性と堅牢性を向上させます。
システムが容量に達したときに、もう1つ注文を処理しようとすると、カーネルのOOMキラーがエンジン全体を終了させ、他の100万件の注文を失う可能性があります。
HNでの議論
30- mrkeen
> TigerStyle: すべてのメモリは起動時に静的に割り当てられなければならない。初期化後は、動的なメモリ割り当て（および解放・再割り当て）を行ってはならない。これにより、パフォーマンスに大きな影響を与えうる予測不可能な動作を回避し、use-after-free を防ぐ。
「動的割り当てなし」という規則の条文は満たしているかもしれないが、その精神を満たしているとは思えない。
NULL オーダーのバッファを書いて、それを呼び出し側に貸し出している（つまり「割り当て」と「再割り当て」をしている）だけではないか？
他人の実戦で鍛えられたアロケータが遅いとかバグがあるとかで、ビジネスロジック実装の一部として自分で書くというのか？
- pjmlp
ここ数十年、何でもスクリプト言語でやる風潮があったせいか、8ビットや16ビットのホビーパソコンのプログラミング技法を、みんなが何年も経ってから再発見しているのが面白い。
- markus0
私は、このような厳格な制約とスタイル/設計ガイドラインを常に守るシステムでもっと働きたいと思っています。しかし同時に、大規模なソフトウェア開発の現実は、チームがプログラムの全体的な運用モデルを考慮しないサブシステムで作業することになりがちだとも感じています。つまり、局所的にはベストプラクティスを守っていても、システム全体としては断片化し非効率になり、厳格なグローバルな制約はかえって制限的に感じられるのです。
- burntcaramel
静的割り当てがこれほど実用的だとは驚いています。制約が強すぎて、常に壁にぶつかるだろうと思っていました。私は Zig/Odin/C で WebAssembly を書いていますが、リンターで `memory.grow` という wasm 命令を拒否させ、コード内では固定サイズのバッファだけを使うようにできています。
「最大画像サイズをどれくらいにしたいか」と考えると、私は 2500 万画素に落ち着きましたが、これは数百メガバイトになります。ほとんどの画像はもっと小さいので、主要なホストでは、最初に読み書きされるまでメモリはページインされないため、実際のメモリフットプリントはもっと小さいと信じています。
- theokrueger
静的割り当ては、明白な理由から組み込み分野では事実上の標準であり、そこで非常にうまく機能しています。動的ワークロードを中心に設計された、より複雑なメモリモデルを持つオペレーティングシステムでは、開発者に新たなハードキャップを課す、もう少し複雑な設計パターンを採用するよう求めることが、以前よりも認知的負荷を減らすことになるとは思えません。
静的割り当ての機能性や正確性の面を否定はできませんが、それは謙虚な連結リストに似ていて、問題に取り組む前にそれが自分に必要だとすでに分かっているべきものです。