Virtuelle Adressräume
Prozessoren verwenden virtuelle Adressen beim Lesen oder Schreiben in Speicherspeicherorte. Während dieser Vorgänge übersetzt der Prozessor die virtuelle Adresse in eine physische Adresse.
Der Zugriff auf Arbeitsspeicher über virtuelle Adressen bietet mehrere Vorteile:
Ein Programm kann einen zusammenhängenden Bereich virtueller Adressen verwenden, um auf einen großen, nicht zusammenhängenden Speicherpuffer im physischen Arbeitsspeicher zuzugreifen.
Ein Programm kann einen Bereich virtueller Adressen verwenden, um auf einen Speicherpuffer zuzugreifen, der größer als der verfügbare physische Arbeitsspeicher ist. Wenn der physische Arbeitsspeicher knapp ist, speichert der Speicher-Manager Seiten physischen Arbeitsspeichers (in der Regel 4 KB groß) in einer Datenträgerdatei. Das System verschiebt Daten- oder Codeseiten nach Bedarf zwischen dem physischen Arbeitsspeicher und dem Datenträger.
Die von verschiedenen Prozessen verwendeten virtuellen Adressen sind isoliert. Der Code in einem Prozess kann den physischen Arbeitsspeicher, der von einem anderen Prozess oder betriebssystem verwendet wird, nicht ändern.
Der Bereich der virtuellen Adressen, der einem Prozess zur Verfügung steht, wird als virtueller Adressraum des Prozesses bezeichnet. Jeder Benutzermodusprozess verfügt über einen eigenen privaten virtuellen Adressraum.
Ein 32-Bit-Prozess verfügt in der Regel über einen virtuellen Adressraum innerhalb des Bereichs von 2 Gigabyte, der bis 0x7FFFFFFF 0x00000000.
Ein 64-Bit-Prozess unter 64-Bit-Windows verfügt über einen virtuellen Adressraum im Bereich von 128 Terabyte 0x000'000000000 bis 0x7FFF'FFFFFFFF.
Ein Bereich virtueller Adressen wird manchmal als Bereich des virtuellen Arbeitsspeichers bezeichnet. Weitere Informationen finden Sie unter Grenzwerte für Arbeitsspeicher und Adressraum.
Das folgende Diagramm veranschaulicht einige wichtige Features virtueller Adressräume.
Das Diagramm zeigt die virtuellen Adressräume für zwei 64-Bit-Prozesse: Notepad.exe und MyApp.exe. Jeder Prozess verfügt über einen eigenen virtuellen Adressraum, der von 0x000'00000000 bis 0x7FF'FFFFFFFF reicht. Jeder schattierte Block stellt eine Seite (4 KB) virtuellen oder physischen Arbeitsspeicher dar. Der Editor-Prozess verwendet drei zusammenhängende Seiten virtueller Adressen ab 0x7F7'93950000. Diese drei zusammenhängenden Seiten virtueller Adressen werden jedoch nicht zusammenhängenden Seiten im physischen Arbeitsspeicher zugeordnet. Außerdem verwenden beide Prozesse eine Seite des virtuellen Arbeitsspeichers ab 0x7F7'93950000. Diese virtuellen Seiten werden jedoch verschiedenen Seiten des physischen Arbeitsspeichers zugeordnet.
Benutzer- und Systembereich
Prozesse wie Notepad.exe und MyApp.exe im Benutzermodus ausgeführt. Kernkomponenten des Betriebssystems und viele Treiber werden im privilegierteren Kernelmodus ausgeführt. Weitere Informationen zu Prozessormodi finden Sie unter Benutzermodus und Kernelmodus.
Jeder Benutzermodusprozess verfügt über einen eigenen privaten virtuellen Adressraum, aber der gesamte Code, der im Kernelmodus ausgeführt wird, verwendet einen einzelnen virtuellen Adressraum namens Systemraum. Der virtuelle Adressraum für einen Benutzermodusprozess wird als Benutzerraum bezeichnet.
In 32-Bit-Windows beträgt der verfügbare virtuelle Adressraum insgesamt 2^32 Bytes (4 Gigabyte). In der Regel werden die unteren 2 Gigabyte für den Benutzerspeicher verwendet, und die oberen 2 Gigabyte werden für den Systemspeicher verwendet.
In 32-Bit-Windows können Sie (zur Startzeit) angeben, dass mehr als 2 Gigabyte für den Benutzerspeicher verfügbar sind. Dies bedeutet jedoch, dass weniger virtuelle Adressen für den Systemspeicher verfügbar sind. Sie können die Größe des Benutzerraums auf bis zu 3 Gigabyte erhöhen, sodass nur 1 Gigabyte Systemspeicher übrig bleibt. Um die Größe des Benutzerbereichs zu erhöhen, verwenden Sie BCDEdit /set increaseuserva.
In 64-Bit-Windows beträgt die theoretische Menge des virtuellen Adressraums 2^64 Bytes (16 Exabyte), aber nur ein kleiner Teil des 16-Exabyte-Bereichs wird tatsächlich verwendet.
Code, der im Benutzermodus ausgeführt wird, kann auf den Benutzerbereich, aber nicht auf den Systemspeicher zugreifen. Diese Einschränkung verhindert, dass Code im Benutzermodus geschützte Betriebssystemdatenstrukturen liest oder ändert. Code, der im Kernelmodus ausgeführt wird, kann sowohl auf den Benutzerspeicher als auch auf den Systemspeicher zugreifen. Das heißt, Code, der im Kernelmodus ausgeführt wird, kann auf den Systemspeicher und den virtuellen Adressraum des aktuellen Benutzermodusprozesses zugreifen.
Treiber, die im Kernelmodus ausgeführt werden, müssen beim direkten Lesen oder Schreiben von Adressen im Benutzerraum vorsichtig sein. Im folgenden Szenario wird veranschaulicht, warum.
Ein Benutzermodusprogramm initiiert eine Anforderung zum Lesen einiger Daten von einem Gerät. Das Programm stellt die Startadresse eines Puffers bereit, um die Daten zu empfangen.
Eine Gerätetreiberroutine, die im Kernelmodus ausgeführt wird, startet den Lesevorgang und gibt die Steuerung an den Aufrufer zurück.
Später unterbricht das Gerät den aktuell ausgeführten Thread, um anzugeben, dass der Lesevorgang abgeschlossen ist. Kernelmodustreiberroutinen behandeln den Interrupt in diesem beliebigen Thread, der zu einem beliebigen Prozess gehört.
Zu diesem Zeitpunkt darf der Treiber die Daten nicht an die Startadresse schreiben, die das Benutzermodusprogramm in Schritt 1 bereitgestellt hat. Diese Adresse befindet sich im virtuellen Adressraum des Prozesses, der die Anforderung initiiert hat, was wahrscheinlich nicht mit dem aktuellen Prozess identisch ist.
Ausgelagerter Pool und nicht ausgelagerter Pool
Im Benutzerbereich können alle physischen Speicherseiten nach Bedarf in eine Datenträgerdatei ausgelagert werden. Im Systembereich können einige physische Seiten ausgelagert werden, andere nicht. Der Systemraum verfügt über zwei Regionen für die dynamische Zuweisung von Arbeitsspeicher: ausgelagerter Pool und nicht ausgelagerter Pool.
Arbeitsspeicher, der im ausgelagerten Pool zugeordnet ist, kann bei Bedarf in eine Datenträgerdatei ausgelagert werden. Arbeitsspeicher, der im nicht ausgelagerten Pool zugeordnet ist, kann niemals in eine Datenträgerdatei ausgelagert werden.
Verwandte Themen
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für