以前、長時間実行される C++ デーモンに取り組んだとき、ヒープの断片化の問題に対処しなければなりませんでした。連続したヒープ領域が不足しないようにするには、大きな割り当てのプールを保持するなどのトリックが必要でした。
これはまだ 64 ビット アドレス空間の問題ですか? パフォーマンスは私にとっては問題ではないので、コードを簡素化し、バッファー プールのようなものはもう扱いません。この問題についての経験や話はありますか? 私は Linux を使用していますが、同じ問題の多くが Windows にも当てはまると思います。
これはまだ64ビットアドレス空間の問題ですか？
いいえ、まだ問題ではありません。
32ビットシステムでは問題でしたが、64ビットシステムでは問題ではなくなりました。
仮想アドレス空間は64ビットシステムでは非常に大きく（現在のx86_64プロセッサでは現在2 ^ 48バイトであり、新しいx86_64プロセッサが登場すると徐々に2 ^ 64に増加するように設定されています）、隣接する仮想アドレス空間が不足します。断片化が原因で、実際には不可能です（非常に工夫されたコーナーケースを除くすべての場合）。
（これは、64が「唯一の」double 32であるという事実によって引き起こされる直感の一般的なエラーであり、64ビットのアドレス空間は32ビットのアドレス空間のおよそ2倍であると人々に思わせます。実際には完全な64ビットアドレス空間は、32ビットアドレス空間の40億倍の大きさです。）
別の言い方をすれば、32ビットデーモンがxバイトブロックを割り当てることができない段階にフラグメント化するのに1週間かかった場合、今日のx86_64プロセッサの48ビットアドレス空間をフラグメント化するのに少なくとも1000年かかるでしょう。将来計画されている完全な64ビットアドレス空間を断片化するには、 8000万年かかるでしょう。
ヒープの断片化は、64 ビットでも 32 ビットと同じくらい大きな問題です。さまざまなライフタイムで多くのリクエストを行うと、断片化されたヒープが得られます。残念ながら、64 ビット オペレーティング システムでは、空きメモリの小さなビットをシャッフルして大きな連続ブロックを作成することがまだできないため、これにはあまり役に立ちません。
ヒープの断片化に対処したい場合でも、同じ古いトリックを使用する必要があります。
ここで 64 ビット OS が役立つ唯一の方法は、決して断片化しない「十分な大きさ」のメモリ量がある場合です。
プロセスが本当にギガバイトの仮想アドレス空間を必要とする場合、64ビットにアップグレードすると、回避策の必要がすぐになくなります。
ただし、プロセスで使用されると予想されるメモリの量を計算することは価値があります。ギガバイト以下の領域にある場合は、クレイジーな断片化でさえ32ビットアドレス空間を使い果たしてしまうことはありません。メモリリークが問題になる可能性があります。
（ちなみに、Windowsは、OSの各プロセスで無礼な量のアドレス空間を予約しているため、より制限が厳しくなります）。