オペレーティングシステムの仮想化の概念とよく混同されます。RAMを物理メモリとして考えると、なぜプロセスを実行するために仮想メモリが必要なのでしょうか。
この仮想メモリは、外部ハードドライブからのプロセス(プログラム)が実行のためにメインメモリ(物理メモリ)に移動されたときにどこに存在しますか。
誰が仮想メモリを管理し、仮想メモリのサイズはどれくらいですか?
RAMのサイズが4GB(つまり、2 ^ 32-1アドレス空間)である場合、仮想メモリのサイズはどれくらいですか?
オペレーティングシステムの仮想化の概念とよく混同されます。RAMを物理メモリとして考えると、なぜプロセスを実行するために仮想メモリが必要なのでしょうか。
この仮想メモリは、外部ハードドライブからのプロセス(プログラム)が実行のためにメインメモリ(物理メモリ)に移動されたときにどこに存在しますか。
誰が仮想メモリを管理し、仮想メモリのサイズはどれくらいですか?
RAMのサイズが4GB(つまり、2 ^ 32-1アドレス空間)である場合、仮想メモリのサイズはどれくらいですか?
回答:
仮想メモリは、とりわけ、システム上で無限のメモリを利用できるという幻想をプログラマに与えるための抽象概念です。
仮想メモリのマッピングは、実際の物理アドレスに対応するように行われます。オペレーティング・システムは、マッピングを維持するために、他のデータ構造の中で、ページテーブルを利用-これらのマッピングを作成して扱っています。仮想メモリのマッピングは常にページテーブルまたは同様のデータ構造にあります(仮想メモリの他の実装の場合、「ページテーブル」と呼ばない方がよいでしょう)。ページテーブルは物理メモリにもあります-多くの場合、ユーザープログラムが上書きできないカーネル予約領域にあります。
通常、仮想メモリは物理メモリよりも大きくなります。仮想メモリと物理メモリが同じサイズであれば、仮想メモリのマッピングに大きな理由はありません。
通常、プログラムの必要な部分のみがメモリに常駐します。これは「ページング」と呼ばれるトピックです。仮想メモリとページングは密接に関連していますが、同じトピックではありません。セグメンテーションなど、仮想メモリの他の実装があります。
私はここで間違っていると思うかもしれませんが、頭を回すのが難しいと思っているのは、仮想メモリの特定の実装、おそらくページングに関係していると思います。ページングを行う方法は1つではありません。多くの実装があり、教科書に記載されている方法は、Linux / Windowsなどの実際のOSに表示されるものとは異なる可能性があります-微妙な違いがあります。
ページングについては1,000段落ほど説明できますが、具体的にはそのトピックを対象とした別の質問に任せた方がよいと思います。
ソフトウェアは非常に単純な前提でOS上で実行されます-それらはメモリを必要とします。デバイスOSは、RAMの形式でそれを提供します。必要なメモリの量はさまざまです。ソフトウェアによっては、大容量のメモリが必要な場合と、わずかなメモリが必要な場合があります。ほとんど(すべてではない)のユーザーがOSで複数のアプリケーションを同時に実行し、メモリが高価(かつデバイスのサイズが有限)であることを考えると、使用可能なメモリの量は常に制限されます。したがって、すべてのソフトウェアが特定の量のRAMを必要とし、それらすべてを同時に実行できるようにすると、OSは次の2つのことに注意する必要があります。
ここでの主な質問は、メモリの管理方法に要約されます。特定のソフトウェアに属するデータがメモリ内のどこに常駐するかを正確に規定するものは何ですか?
考えられる解決策1:個々のソフトウェアに、デバイスで使用するメモリアドレスを明示的に指定させます。仮定Photoshopは、それは常に至るまでのメモリアドレスを使用することを宣言する
0
には1023
(その最初のバイトが場所にある、バイトの線形アレイとしてメモリを想像して0
、1024
目のバイトが場所にある1023
) -すなわち占有1 GB
メモリ。同様に、VLCは1244
からまでのメモリ範囲を占有することを宣言します1876
。
利点:
短所:
これはスケーリングしません。理論的には、アプリが非常に負荷の高いものを実行しているとき、アプリは大量のメモリを必要とする場合があります。したがって、メモリが不足しないようにするには、割り当てられるメモリ領域が常にそのメモリ量以上である必要があります。最大の理論上のメモリ使用量2 GB
(したがって2 GB
RAMからのメモリ割り当てが必要)のソフトウェアが、メモリのみのマシンにインストールされている場合は1 GB
どうなりますか?ソフトウェアは、使用可能なRAMが少ないと言って、起動時に中止する必要があり2 GB
ますか?それとも続行する必要2 GB
がありますか?必要なメモリがを超えた瞬間に、中止して、メモリが足りないというメッセージを表示してベイルアウトしますか?
メモリのマングルを防ぐことはできません。数百万ものソフトウェアが世の中に存在し、それらのそれぞれに1 kB
メモリのみが割り当てられていたとしても、必要な合計メモリはを超え16 GB
、これはほとんどのデバイスが提供するものを超えています。では、どのようにして、異なるソフトウェアに、互いの領域に侵入しないメモリスロットを割り当てることができるのでしょうか。第一に、新しいソフトウェアがリリースされているときに、このまだ占有されていない領域から多くのメモリを割り当てる必要があることを規制できる集中型ソフトウェア市場はありません。、そして第二に、たとえあったとしても、それができないのでそれを行うことは不可能です。ソフトウェアの数は事実上無限であり(したがって、それらのすべてに対応するために無限のメモリが必要です)、任意のデバイスで使用可能なRAMの合計は、必要なもののほんの一部でも対応するのに十分ではないため、1つのソフトウェアのメモリ境界の侵害を避けられません。別のものの。だから何が起こるとき、Photoshopはメモリ位置を割り当てられている1
に1023
してVLCが割り当てられている1000
に1676
?Photoshopが場所1008
にデータを保存している場合、VLCはそれを独自のデータで上書きし、その後Photoshop以前にそこに格納されていたのと同じデータであると考えてアクセスしますか?ご想像のとおり、悪いことが起こります。
明らかに、ご覧のとおり、このアイデアはかなり素朴です。
考えられる解決策2:OSがメモリ管理の大部分を行う別のスキームを試してみましょう。ソフトウェアは、メモリを必要とするときはいつでも、OSを要求するだけであり、OSはそれに応じて対応します。たとえば、OSが新しいプロセスがメモリを要求するときは常に、可能な限り低いバイトアドレスからメモリが割り当てられることを保証します(前述のように、RAMはバイトの線形配列として想像できるため、
4 GB
RAMの場合、アドレス範囲はバイト0
へ2^32-1
)プロセスが開始中の場合、またはそれがメモリを要求する実行中のプロセスである場合、そのプロセスがまだ存在する最後のメモリ位置から割り当てます。ソフトウェアは、そのデータが格納される実際のメモリアドレスが何であるかを考慮せずにアドレスを発行するため、OSはソフトウェアによって発行されたアドレスと実際の物理アドレスのマッピングを維持する必要があります(注:これが、この概念を呼び出す2つの理由の1つですVirtual Memory
。ソフトウェアは、データが格納される実際のメモリアドレスを気にせず、ただちにアドレスを吐き出すだけであり、OSはそれに適合する適切な場所を見つけて見つけます。後で必要に応じて)。
デバイスの電源がオンになり、OSが起動したばかりで、現在、他のプロセスが実行されておらず(OSは無視されます。これもプロセスです!)、VLCを起動するとします。したがって、VLCには、RAMの一部が最下位バイトアドレスから割り当てられます。良い。ビデオの再生中に、ブラウザを起動してWebページを表示する必要があります。次に、メモ帳を起動してテキストを落書きします。そして、Eclipseでコーディングを実行します。まもなく、4 GB
すべてのメモリが使い果たされ、RAMは次のようになります。
問題1:すべてのRAMが使い果たされたため、他のプロセスを開始できない。したがって、利用可能な最大メモリを念頭に置いてプログラムを作成する必要があります(他のソフトウェアも並行して実行されるため、実際には利用可能なメモリはさらに少なくなります!)。言い換えれば、メモリを大量に消費するアプリを手に負えない
1 GB
PC で実行することはできません。
さて、EclipseとChromeを開いたままにする必要がないと判断したので、それらを閉じてメモリを解放します。これらのプロセスによってRAMに占有されていたスペースは、OSによって解放され、次のようになります。
これら2つを閉じると700 MB
領域が解放されると仮定します-(400
+ 300
)MB。次に、スペースを占有するOperaを起動する必要があります450 MB
。まあ、あなたは450 MB
合計で利用できる以上のスペースを持っていますが...それは隣接していません、それは個々のチャンクに分割され、どれも収まるのに十分な大きさではありません450 MB
。あなたは素晴らしいアイデアを思いついたので、以下のすべてのプロセスを可能な限り上に移動します700 MB
。これにより、下部の1つのチャンクに空のスペースが残ります。これはcompaction
。すばらしいですが、そこにあるすべてのプロセスが実行されています。それらを移動することは、すべてのコンテンツのアドレスを移動することを意味します(OSは、ソフトウェアによって生成されたメモリのマッピングを実際のメモリアドレスに維持することを忘れないでください。ソフトウェアがアドレス45
付きのデータ123
を生成し、OSがその場所にそれを格納したことを想像してください。2012
マップにエントリを作成し、にマッピング45
し2012
ます。ソフトウェアがメモリ内に移動された場合、以前の場所にあったもの2012
がでなく2012
新しい場所にあり、OSはそれに応じてマップ45
を更新する必要があります。新しいアドレス。これにより、ソフトウェアは123
、メモリの場所を照会するときに期待されるデータ()を取得できます45
。ソフトウェアに関する限り、ソフトウェアが知っているのはそのアドレスだけです。45
データが含まれています123
!)!ローカル変数を参照しているプロセスを想像してくださいi
。再びアクセスされるまでに、アドレスが変更されており、それを見つけることができなくなります。同じことがすべての関数、オブジェクト、変数に当てはまり、基本的にすべてにアドレスがあります。プロセスを移動すると、それらすべてのアドレスが変更されます。それは私たちにつながる:
問題2:プロセスを移動できない。そのプロセス内のすべての変数、関数、およびオブジェクトの値は、コンパイル中にコンパイラーによって吐き出されるようにハードコードされた値を持ちます。その結果、プロセス
holes
は終了時に大きな " "を残します。これをと呼びExternal Fragmentation
ます。
いいよ どういうわけか、奇跡的な方法で、プロセスを上に移動することができたとします。今700 MB
下部に空きスペースがあります:
Operaは下部にスムーズに収まります。これで、RAMは次のようになります。
良い。すべて問題ありません。ただし、十分なスペースが残っていないため、既知のメモリ消費であるChromeを再度起動する必要があります。開始するには大量のメモリが必要で、残りはほとんどありません...例外を除いて..最初は大きなスペースを占めていたプロセスの一部が、今では多くのスペースを必要としていません。VLCでビデオを停止した可能性があります。そのため、高解像度のビデオを実行しているときに必要なだけではなく、ある程度のスペースを占有しています。同様にメモ帳と写真。RAMは次のようになります。
Holes
、 もう一度!振り出しに戻って!以前は、プロセスの終了が原因で発生していた穴を除いて、現在はプロセスが以前よりも少ないスペースで済みます。また、同じ問題があります。holes
結合すると必要以上のスペースが生じますが、それらは分散しており、単独で使用することはあまりありません。したがって、これらのプロセスを再度移動する必要があります。コストのかかる操作であり、非常に頻繁に行われます。これは、プロセスのライフタイムを通じてサイズが減少することが多いためです。
問題3:プロセスは、その存続期間を通じてサイズが減少し、未使用のスペースが残る場合があります。未使用のスペースを使用する必要がある場合は、多くのプロセスを移動するための高価な操作が必要になります。これをと呼び
Internal Fragmentation
ます。
これで、OSが必要な処理を実行し、プロセスを移動してChromeを起動します。しばらくすると、RAMは次のようになります。
涼しい。今、あなたはもう一度見て再開したとアバターにVLC。そのメモリ要件は急上昇します!ただし、メモ帳の下部が寄り添っているので、拡張するためのスペースは残っていません。したがって、VLCが十分なスペースを見つけるまで、すべてのプロセスは下に移動する必要があります。
問題4:プロセスが成長する必要がある場合、それは非常に高価な操作になります
いいね。ここで、Photosを使用して、外付けハードディスクから写真をロードするとします。ハードディスクにアクセスすると、キャッシュとRAMの領域からディスクの領域に移動します。これは、桁違いに遅いです。痛みを伴う、取り返しのつかないほど、超越的に遅い。これはI / O操作です。つまり、CPUバウンドではありません(正反対です)。つまり、現在RAMを占有する必要はありません。ただし、それでもRAMを頑固に占有します。その間にFirefoxを起動したい場合は、メモリが不足しているために起動できませんが、I / Oバウンドアクティビティの期間中にフォトがメモリから取り出された場合は、大量のメモリが解放されます。 (高価な)圧縮が続き、続いてFirefoxが組み込まれます。
問題5:I / OにバインドされたジョブがRAMを占有し続けるため、RAMの使用率が低下し、それまではCPUにバインドされたジョブで使用されていた可能性があります。
ご覧のとおり、仮想メモリのアプローチを使用しても、非常に多くの問題があります。
これらの問題に取り組むには2つのアプローチがあります- paging
とsegmentation
。話し合いましょうpaging
。このアプローチでは、プロセスの仮想アドレス空間はチャンクと呼ばれる物理メモリにマップされpages
ます。典型的なpage
サイズは4 kB
です。マッピングはと呼ばれるものによって維持されpage table
、仮想アドレスが指定された後page
、アドレスがどのアドレスに属しているかを調べ、次にから、実際の物理メモリ(と呼ばれる)内のpage table
対応する場所を見つけ、内の仮想アドレスのオフセットがとで同じである場合は、から返されるアドレスにそのオフセットを追加して、実際のアドレスを見つけます。例えば:page
frame
page
page
frame
page table
左側はプロセスの仮想アドレス空間です。仮想アドレス空間に40単位のメモリが必要だとします。物理アドレス空間(右側)にも40単位のメモリがある場合、すべての場所を左から右の場所にマップすることができたので、私たちはとても幸せでした。しかし、運が悪ければ、物理メモリのメモリユニットが少ない(ここでは24)だけでなく、複数のプロセス間でも共有する必要があります。よし、それでどうやってやるのか見てみよう。
プロセスが開始したら、ロケーションのメモリアクセス要求35
が行われたと言います。ここではページサイズがある8
(それぞれがpage
含まれている8
場所を、全体の仮想アドレス空間40
の場所は、このように含まれている5
ページ)。したがって、この場所はページ番号に属しています。4
(35/8
)。この内でpage
、この場所のオフセットは3
(35%8
)です。したがって、この場所はtuple (pageIndex, offset)
=で指定できます(4,3)
。これはほんの始まりに過ぎないため、プロセスのどの部分も実際の物理メモリにはまだ保存されていません。したがって、はpage table
、左側のページと右側の実際のページ(呼び出される場所)のマッピングを維持します。frames
)は現在空です。したがって、OSはCPUを放棄し、デバイスドライバーがディスクにアクセスしてページ番号をフェッチできるようにします。4
この過程(アドレス範囲ディスク上のプログラムから、基本的にメモリのチャンクのため32
に39
)。それが到着すると、OSはRAMのどこかに、たとえば最初のフレーム自体を割り当てます。page table
このプロセスでは、ページがRAMの4
フレーム0
にマップされることに注意してください。これで、最終的にデータが物理メモリに格納されました。OSは再びタプルのページテーブルをクエリし、(4,3)
今回は、ページ4
が0
RAMのフレームに既にマップされていることをページテーブルが示しています。したがって、OSは単に0
RAM のth番目のフレームに移動し3
、そのフレームのオフセットでデータにアクセスします(これを理解するために少し時間をかけてください。全体page
ディスクからフェッチされたがに移動されframe
ます。したがって、ページ内の個々のメモリ位置のオフセットが何であれ、フレーム内でも同じになります。これは、page
/ 内ではframe
、メモリユニットがまだ同じ場所にあるためです。)、データを返します。データは最初のクエリ自体ではメモリ内に見つかりませんでしたが、メモリにロードするためにディスクからフェッチする必要があったため、ミスになります。
いいね。ここで、場所のメモリアクセス28
が行われたと仮定します。沸騰し(3,4)
ます。Page table
現在のところ、ページ4
をフレームにマッピングするエントリは1つだけ0
です。したがって、これもミスであり、プロセスはCPUを放棄し、デバイスドライバはディスクからページをフェッチし、プロセスは再びCPUの制御を取り戻し、page table
更新されます。ここで、ページ3
が1
RAMのフレームにマップされているとします。したがって、(3,4)
となり(1,4)
、RAM内のその場所にあるデータが返されます。良い。このようにして、次のメモリアクセスが場所8
であるとすると、これはに変換され(1,0)
ます。ページ1
はまだメモリにありません。同じ手順が繰り返され、page
フレームに割り当てられます2
RAM内。これで、RAMプロセスのマッピングは上の図のようになります。この時点で、24ユニットのメモリしか利用できなかったRAMがいっぱいになります。このプロセスの次のメモリアクセス要求がアドレスからであるとします30
。それはにマップされ(3,6)
、page table
そのページ3
はRAM内にあり、frameにマップされます1
。わーい!したがって、データはRAMの場所からフェッチされ(1,6)
、返されます。これは、構成のヒットを必要とするデータは、このように非常に高速であること、RAMから直接取得することができるよう、。同様に、次のいくつかのアクセス要求が、場所について言う11
、32
、26
、27
すべてのあるヒット、すなわちデータは、プロセスが要求した他の場所で見る必要がなくRAMに直接発見されました。
ここで、位置のメモリアクセス要求が3
来たとします。これはに変換され(0,3)
、page table
このプロセスでは現在3つのエントリがページ1
に3
あり4
、このページはメモリにないことを示しています。以前のケースと同様に、ディスクからフェッチされますが、以前のケースとは異なり、RAMはいっぱいです。それで、今何をすべきか?ここに仮想メモリの美しさがあります。RAMからフレームが削除されます!(さまざまな要因が、どのフレームが追い出されるかを決定します。それはLRU
、プロセスのために最も最近アクセスされていないfirst-come-first-evicted
フレームが追い出されることに基づいている場合があります。それは、最も長い時間前に割り当てられたフレームが追い出される場合などに基づいています。。)そのため、一部のフレームが削除されます。フレーム1と言います(ランダムに選択するだけです)。ただし、それframe
はpage
!(現在、ページテーブルによって、3
1つだけのプロセスのページにマップされています)。したがって、そのプロセスは、この悲劇的なニュースを伝えるframe
必要があります。残念なことに、あなたの所有するものは、RAMから追い出されて、別ののための余地を作ることpages
です。プロセスはpage table
、この情報でページを更新することを確認する必要があります。つまり、そのページフレームデュオのエントリを削除して、次にそのリクエストが行われたpage
ときにpage
、メモリに存在しないことをプロセスに伝えます。 、およびディスクからフェッチする必要があります。良い。したがって、フレーム1
が削除され、0
ページ3
がRAMに取り込まれて配置され、ページのエントリが削除され、0
同じフレームへのページマッピングに置き換えられます。1
。したがって、マッピングは次のようになります(frame
右側の2番目の色の変化に注意してください)。
何が起こったのか見ましたか?プロセスは成長する必要があり、使用可能なRAMよりも多くのスペースが必要でしたが、RAMのすべてのプロセスが成長するプロセスに対応するために移動する必要があった以前のシナリオとは異なり、ここでは1回のpage
交換で発生しました。これは、プロセスのメモリが連続している必要がなく、チャンク内のさまざまな場所に常駐でき、OSがそれらの場所に関する情報を維持し、必要に応じて適切に照会されるという事実によって可能になりました。注:ほとんどの場合、それがmiss
であり、データをディスクからメモリに常にロードする必要がある場合はどうなるでしょうか。はい、理論的には可能ですが、ほとんどのコンパイラは次のように設計されていますlocality of reference
つまり、あるメモリロケーションからのデータが使用されている場合、次に必要なデータはpage
、page
メモリにロードされた同じ場所からの非常に近い場所に配置されます。その結果、次のミスはかなりの時間が経過すると発生します。次のメモリ要件のほとんどは、取り込んだばかりのページ、または最近メモリですでに使用されているページによって満たされます。まったく同じ原則によりpage
、しばらく使用されていないものはしばらく使用されない可能性が高いというロジックを使用して、最も最近使用されていないものを排除することもできます。ただし、常にそうであるとは限りません。例外的なケースでは、はい、パフォーマンスが低下する可能性があります。後で詳しく説明します。
問題4の解決策:プロセスは簡単に拡大できるようになりました。スペースの問題が発生した場合
page
、他のプロセスを移動せずに単純な置換を行うだけで済みます。
問題1の解決策:プロセスは無制限のメモリにアクセスできます。利用可能なメモリより多くのメモリが必要な場合、ディスクはバックアップとして使用され、必要な新しいデータがディスクからメモリにロードされ、最も使用頻度の低いデータ
frame
(またはpage
)がディスクに移動されます。これは無限に続く可能性があり、ディスク領域は安価で事実上無制限であるため、無制限のメモリのように見えます。名前のもう1つの理由は、Virtual Memory
実際には利用できないメモリのように見えることです。
涼しい。以前は、プロセスのサイズが小さくなっても、空のスペースを他のプロセスで再生することが困難であるという問題に直面していました(コストのかかる圧縮が必要になるため)。簡単になりました。プロセスのサイズが小さくなると、その多くはpages
使用されなくなります。したがって、他のプロセスがより多くのメモリを必要とする場合、単純なLRU
ベースのエビクションはpages
、RAMからそれらの使用されていないものを自動的に追い出し、それらを新しいページに置き換えます他のプロセス(もちろん、page tables
これらのすべてのプロセスと、必要なスペースが少ない元のプロセスの更新)。これらすべてに、コストのかかる圧縮操作はありません。
問題3の解決策:プロセスのサイズ
frames
が小さくなると、RAM内の使用が減るので、単純なLRU
ベースのエビクションでそれらのページを追い出しpages
、新しいプロセスが必要とするページに置き換えることができるためInternal Fragmentation
、の必要性を回避できますcompaction
。
問題2については、少し時間をかけて理解してください。シナリオ自体は完全に削除されています。新しいプロセスに対応するためにプロセスを移動する必要はありません。これは、プロセス全体が一度にフィットする必要がなくframes
、RAMからの追い出しによって発生する特定のページだけがアドホックにフィットする必要があるためです。すべてがの単位で発生するためpages
、hole
現在の概念はなく、したがって、何かが動いているという疑問はありません。pages
この新しい要件のために10 を移動する必要があった可能性がありますpages
。一方、以前は、すべてのプロセス(そのすべて)を移動する必要がありました。
問題2の解決策:新しいプロセスに対応するには、他のプロセスの最近使用されていない部分のみからのデータを必要に応じて排除する必要があり、これはと呼ばれる固定サイズの単位で行われ
pages
ます。こうしての可能性がないhole
か、External Fragmentation
このシステムとは。
プロセスがI / O操作を実行する必要がある場合、CPUを簡単に解放できます。OSは単にそのすべてをpages
RAMから削除します(おそらくそれを何らかのキャッシュに保存します)一方で、新しいプロセスはその間にRAMを占有します。I / O操作が完了すると、OSはそれらpages
を単にRAMに復元します(もちろん、pages
他のいくつかのプロセスからを置き換えることによって、元のプロセスを置き換えたプロセスからのものである場合もあれば、I / Oを実行する必要があるプロセスからのものである場合もあります)さあ、記憶を放棄することができます!)
問題5の解決策:プロセスがI / O操作を実行しているときに、他のプロセスが利用できるRAMの使用を簡単に放棄できます。これにより、RAMが適切に使用されます。
そしてもちろん、現在、RAMに直接アクセスしているプロセスはありません。各プロセスは、物理RAMアドレスにマップされ、page-table
そのプロセスによって維持される仮想メモリの場所にアクセスしています。マッピングはOSによってサポートされ、OSはプロセスにどのフレームが空であるかを知らせ、プロセスの新しいページをそこに合わせることができます。このメモリ割り当てはOS自体によって監視されるため、RAMから空のフレームのみを割り当てるか、RAM内の別のプロセスのコンテンツに侵入してプロセスに通信することにより、プロセスが別のプロセスのコンテンツに侵入しないことを簡単に確認できます。それを更新するpage-table
。
元の問題の解決策:割り当て全体がOS自体によって管理され、すべてのプロセスが独自のサンドボックス仮想アドレススペースで実行されるため、プロセスが別のプロセスのコンテンツにアクセスする可能性はありません。
したがって、paging
(他の手法の中でも)仮想メモリと組み合わせて、OS-esで実行されている今日のソフトウェアを強化します。これにより、ソフトウェア開発者は、ユーザーのデバイスで利用可能なメモリの量、データの保存場所、他のプロセスがソフトウェアのデータを破損しないようにする方法などについて心配する必要がなくなります。ただし、完全な保証ではありません。欠陥があります:
Paging
最終的には、ディスクをセカンダリバックアップとして使用することにより、無限のメモリのような錯覚をユーザーに与えます。メモリに収まるようにセカンダリストレージからデータを取得する(と呼ばれpage swap
、RAMで目的のページが見つからないというイベントはと呼ばれますpage fault
)とは、IO操作であるため負荷がかかります。これはプロセスを遅くします。このようなページスワップがいくつか連続して発生し、プロセスが非常に遅くなります。ソフトウェアが正常に動作しているのを見たことがありますか?突然、非常に遅くなり、ほとんどハングするか、再起動するオプションがなくなりますか?おそらく、ページスワップが多すぎて遅くなりました(と呼ばれますthrashing
)。OPに戻って、
プロセスを実行するために仮想メモリが必要なのはなぜですか?-答えが詳細に説明されているように、ソフトウェアに無限メモリを備えたデバイス/ OSの幻想を与えることで、たとえメモリ割り当てや他のプロセスがデータを破壊することを心配せずに、大小のソフトウェアを実行できるようにします。並列実行。これは、さまざまな手法を通じて実際に実装される概念であり、その1つは、ここで説明するように、ページングです。また、セグメンテーションかもしれません。
外部ハードドライブからのプロセス(プログラム)が実行のためにメインメモリ(物理メモリ)に読み込まれたとき、この仮想メモリはどこにあるのですか?-仮想メモリはそれ自体どこにも立っていない、それは抽象化であり、常に存在し、ソフトウェア/プロセス/プログラムが起動されると、新しいページテーブルが作成され、それによって生成されたアドレスからのマッピングが含まれます。 RAM内の実際の物理アドレスに処理します。プロセスによって吐き出されたアドレスは実際のアドレスではないため、ある意味では、実際に言うことができますthe virtual memory
。
仮想メモリは誰が管理し、仮想メモリのサイズはどのくらいですか?-OSとソフトウェアが連携して処理します。ローカル変数-を含むコード内の関数(最終的にコンパイルされ、プロセスを生成する実行可能ファイルにされた)を想像してくださいint i
。コードが実行されるi
と、関数のスタック内のメモリアドレスを取得します。その関数自体は、別の場所にオブジェクトとして保存されます。これらのアドレスはコンパイラー生成(コードを実行可能ファイルにコンパイルしたコンパイラー)-仮想アドレスです。実行されると、i
少なくともその関数の持続時間の間(静的変数でない限り)、実際の物理アドレスのどこかに存在する必要があるため、OSはコンパイラが生成した仮想アドレスをマップします。i
その関数内で一部のコードがの値を必要とするときはいつでも、i
そのプロセスはOSにその仮想アドレスを問い合わせることができ、OSは格納されている値の物理アドレスを問い合わせ、それを返すことができます。
RAMのサイズが4GB(つまり、2 ^ 32-1アドレス空間)である場合、仮想メモリのサイズはどれくらいですか?-RAMのサイズは仮想メモリのサイズとは関係なく、OSに依存します。たとえば、32ビットWindowsでは16 TB
64ビットWindowsではです256 TB
。もちろん、メモリがバックアップされるので、ディスクサイズによっても制限されます。
こちらをご覧ください: 物理対仮想メモリ
仮想メモリはハードドライブに保存され、RAMがいっぱいになったときに使用されます。物理メモリは、コンピュータにインストールされているRAMチップのサイズに制限されています。仮想メモリはハードドライブのサイズによって制限されるため、仮想メモリにはより多くのストレージを搭載できます。