最も基本的な利点は、プロセスが仮想メモリを物理的に割り当てる方法を心配する必要がないようにする抽象化層を提供することであり、これはオペレーティングシステムで処理されることがわかります。しかし、他にどのような利点/欠点が期待できますか？
ベストアンサー1
各プロセスは、コンピューティングの最初に行ったように、一度に1台のコンピュータで実行される単一のプログラムモデルに従う一意のアドレス空間を持ちます。最新の時分割オペレーティングシステムでは、プロセスはまだ専用のCPUとメモリを使用して実行されているかのように世界を見ています。 （これは少し単純化されています。プロセスはもちろん、IPCメカニズムを介して他のプロセスについて学ぶことができます。）
次に、代替コンピュータで実行されているすべてのプロセスが共有するアドレス空間を見てみましょう。プログラムの起動時に実行中のプロセスはメモリアドレスをすでに使用しているため、プログラムがメモリにロードされたときにメモリセグメントを再配置する必要があります。プログラムのメモリレイアウトは毎回異なる場合があり、プログラムは開始する前に「即時」再接続する必要があります。
共有メモリ空間は、異なるプロセスに属するページをメモリ空間全体に分散させることによって達成できます。これを行うには、各メモリ領域（ページまたはセグメント）がその領域を所有するプロセスに関する情報に関連付けられる高度な保護スキームをハードウェアに実装する必要があります。また、このソリューションには、メモリが断片化され、プログラムのロードに失敗する可能性があるという欠点もあります。これは、連続したメモリアドレスを持つ大きな領域が必要になる可能性があり、十分に大きな領域を使用できない可能性があるためです。
別のアプローチは、各プロセスに対して連続的なメモリ空間を確保することである。これにより保護スキームがより単純になりますが（下限と上限のみ）、アドレス空間が無駄になり、断片化が発生します。
これに多少関連しているのは、多くの非関連プロセスで共有するコードとデータを含む共有ライブラリです。共有ライブラリのページは、変更されていない状態（つまり、プロセス固有の絶対アドレスパッチなし）でメモリにロードされるのが理想的です。そうしないと、プロセス間で物理メモリフレームを共有できません。一方、共有ライブラリは、異なるプロセスの異なる仮想アドレスにロードする必要があることがよくあります。そうしないと、扱いにくくなります。最新の共有ライブラリは、位置に依存しないコードを使用し、間接参照を介してデータにアクセスするため、ほとんど変更されていないまま、他の仮想アドレスを使用して実行を続けることができます。第1世代のLinux "a.out"共有ライブラリは実際にはより単純で、アドレス空間の固定位置にロードされました。これを行うには、既知の共有ライブラリごとに仮想アドレスの中央レジストリを維持し、将来の成長のためにいくつかの追加スペースを予約する必要があります。