私のかなり一般的な質問を申し訳ありませんが、私はそれに対する明確な答えを見つけることができませんでした:
空きスワップメモリが残っていて、適切なチャンク(〜1MB)でメモリを割り当てている場合、何らかの理由でメモリ割り当てが失敗する可能性はありますか?
スマートアスの答えは、「はい、何らかの理由でメモリ割り当てが失敗する可能性があります」です。それはあなたが探しているものではないかもしれません。
一般に、システムに空きメモリが残っているかどうかは、割り当てが成功するかどうかとは関係ありません。むしろ、問題は、プロセスのアドレス空間に空き仮想アドレス空間があるかどうかです。
アロケータ(、、malloc
... )は、最初に、現在のプロセスにすでにマップされoperator new
ている空きアドレススペースがあるかどうかを確認します。つまり、カーネルはアドレスが使用可能であることを認識しています。存在する場合、そのアドレススペースはアロケータで予約されて返されます。
それ以外の場合、カーネルは新しいアドレス空間をプロセスにマップするように求められます。これは失敗する可能性がありますが、マッピングはまだ物理メモリの使用を意味しないため、通常は失敗します。誰かがこのアドレスにアクセスしようとすると、カーネルが物理メモリを見つけてMMUテーブルを設定しようとすることは約束です。したがって、仮想->物理変換がそれを見つけます。
システムのメモリが不足すると、物理メモリがなくなり、プロセスが一時停止され、カーネルは他のプロセスのメモリをディスクに移動して物理メモリを解放しようとします。単一のアセンブラ命令の実行に明らかに長い時間がかかったことを除いて、アプリケーションはこれに気づきません。
十分な大きさのマップされた空き領域がなく、カーネルがマッピングの確立を拒否した場合、プロセスでのメモリ割り当ては失敗します。たとえば、ほとんどのオペレーティングシステムがカーネルを特定のアドレス(通常、0x80000000、0xc0000000、0xe0000000などの32ビットアーキテクチャ)にマップするため、すべての仮想アドレスが使用できるわけではありません。そのため、プロセスごとの制限は、より低くなる可能性があります。システム制限(たとえば、Windowsの32ビットプロセスは、システムが64ビットであっても、2 GBしか割り当てることができません)。ファイルマッピング(プログラム自体やDLLなど)は、使用可能なスペースをさらに削減します。
非常に一般的で理論的な答えはノーです、それはできません。非常に特殊な状況で失敗する可能性がある理由の1つは、使用可能な/割り当て可能なメモリの奇妙な断片化が発生することです。あなたが(おそらく非常にマイナーな)パフォーマンスの向上を試みているのか(ポインタ== NULLの場合はスキップする-ある種のこと)、それともただ疑問に思ってそれについて話し合いたいのか、その場合はおそらくチャットを使用する必要があります。
はい。32ビットアプリケーションでメモリスペースが不足すると、メモリ割り当てが失敗することがよくあります(OSのバージョンと設定に応じて2、3、または4 GBになる可能性があります)。これは、メモリリークが原因である可能性があります。OSがスワップファイルのスペースを使い果たした場合にも失敗する可能性があります。