静的割り当てと一定の作業：メモリ安全性の死角を回避する
Static Allocation, Constant Work
この記事では、メモリ安全性の難しい問題に対する実践的な解決策を探ります。著者は、型なしのアロケータが引き起こす型混乱を避けるために、型分離プールを使用する方法を提案します。さらに、動的割り当てを排除する静的割り当てと、常に一定の作業量を保証する「一定の作業」の原則を紹介します。これらの手法は、TigerBeetleのコードベースで実際に適用されており、パフォーマンスの予測可能性と堅牢性を向上させます。
システムが容量に達したときに、もう1つ注文を処理しようとすると、カーネルのOOMキラーがエンジン全体を終了させ、他の100万件の注文を失う可能性があります。
HNでの議論
17- mrkeen
> TigerStyle: すべてのメモリは起動時に静的に割り当てられなければならない。初期化後にメモリを動的に割り当て（または解放して再割り当て）してはならない。これにより、パフォーマンスに大きな影響を与える予測不可能な動作を回避し、use-after-freeを防ぐ。
NULLオーダーの配列を維持することは「動的割り当てなし」という法律の文言を満たすかもしれませんが、精神を満たしているとは思いません。
あなたは単にNULLオーダーのバッファを書いて、それを呼び出し側に貸し出している（つまり「割り当て」と「再割り当て」をしている）だけではありませんか？
他の誰かの実戦で鍛えられたアロケータが遅いかバグがあるかもしれないので、ビジネスロジック実装の一部として独自のものを書くのですか？
- markus0
私は常にそのような厳格な制約とスタイル/設計ガイドラインに従うシステムで働きたいと思っていますが、同時に、大規模なソフトウェア構築の現実は、チームがプログラムの全体的な運用モデルを考慮しないサブシステムで作業することになる、と感じています。そのため、局所的にはベストプラクティスがあっても、システム全体としては断片化され非効率になり、厳格なグローバルな制約は制限的に感じられます。
- pjmlp
8ビットや16ビットのホームコンピュータのプログラミングテクニックを、これだけの年月を経て誰もが再発見しているのは興味深いですね。おそらく、ここ20年の間に何でもスクリプト言語で書くことが原因でしょう。