4-GB-Grenze

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

Die 4-GB-Grenze (auch 4-GiB-Grenze) bezeichnet die maximale Größe eines Adressraums (zum Beispiel des Arbeitsspeichers), der mit 32 Bit großen Adressen bei byteweiser Adressierung verwendet werden kann, zum Beispiel durch einen Prozess unter einem 32-Bit-Betriebssystem. Manche 32-Bit-Architekturen können mittels Segmentierungstechniken einen größeren Adressraum bereitstellen.

Problembeschreibung[Bearbeiten]

Das Problem tritt insbesondere bei Rechnerarchitekturen auf, die zur Adressierung von Daten im Arbeitsspeicher 32 Bit lange Adressen (unsigned Integer) verwenden. Durch diese Beschränkung ist es den betroffenen Prozessoren nicht möglich, mehr als 232 Byte, also 4 GiB, anzusprechen. Diese Einschränkung gilt sowohl für den logischen (virtuellen) Adressraum, den das Programmen anspricht, als auch für den physischen Adressraum - den im System tatsächlich installierten Arbeitsspeicher. Selbst wenn der real installierte Arbeitsspeicher eines Computers kleiner als 4 GiB ist, kann die 4-GiB-Grenze auf einige Programme Auswirkungen haben, etwa auf Anwendungen, die große memory-mapped Dateien verwenden.

3-GB-Barriere[Bearbeiten]

Manchmal verschärft sich das Problem auf eine 3-GB-Barriere oder eine 2-GB-Barriere.

Realer Adressraum

Der verwendbare Bereich des realen Adressraums kann durch weitere Einflüsse von Hardware (Hauptplatine, I/O-Geräten ~ insbesondere die Größe des Video-RAM) und/oder das Betriebssystem weiter eingeschränkt werden. Gängige Computerarchitekturen zweigen realen Adressraum für die Einblendung von System-ROM und IO-Bereichen ab, z. B. Onboard- und Erweiterungshardware wie Grafik- und Soundkarten (Shared Memory/Unified Memory Architecture). Im x86-Umfeld sind 2,0 bis 3,75 GiB RAM üblicherweise nutzbar, die genauen Werte hängen vom Mainboard und dem Ausbau an internen Erweiterungskarten sowie von den BIOS-Einstellungen ab. Auch steht der verwendbare Bereich mitunter nicht lückenlos zur Verfügung, sondern ist zwischen 2,0 und 4,0 GiB fragmentiert.

Virtueller Adressraum

Außerdem kann unter üblichen 32-bit Betriebssystemen ein einzelner 32-Bit-Prozess nicht mehr als 2 GiB (Microsoft Windows) bzw. 3 GiB (Linux[1]) virtuellen Adressraum belegen, da der obere Teil des 4-GiB-Adressraums fest dem Betriebssystem zugeordnet ist und nicht durch Anwendungsprogramme alloziert werden kann.

Unter 32-bit Windows Betriebssystemen kann die feste Zuteilung von 2 GiB an das Betriebssystem auf 1 GiB reduziert werden (/3GB switch[2]). Um dies zu nutzen muss außerdem das IMAGE_FILE_LARGE_ADDRESS_AWARE -Flag im Header der Anwendung aktiviert sein; dann sind mit einer 32-Bit-Anwendung bis zu 3 GiB auf einem 32-Bit-Windows, bzw. 4 GiB virtueller Adressraum auf einem 64-Bit-Windows möglich.[3]

Problembehebung[Bearbeiten]

Die 4-GiB-Grenze ist nicht vorhanden, wenn ein 64-Bit-System (Betriebssystem und Anwendung) zum Einsatz kommt. Hier liegt die theoretische Grenze des Adressraums bei 264 Byte, also 16 Exbibyte. Viele Prozessoren, wie die der AMD64-Architektur, verfügen zwar über mehr als 32 aber weniger als 64 Adressleitungen und können somit weniger als 16 Exbibyte Arbeitsspeicher ansprechen. Der physische Adressraum ist also auch hier wesentlich kleiner. Eine Problematik der Verbreiterung der Adressen ist, dass 64-Bit-Betriebssysteme nur 64-Bit-Kernel-Treiber verwenden können, weil in diesem Fall der Betriebssystemkern 64-bittig implementiert ist und Kernel-Treiber direkt im Adressraum des Betriebssystemkerns ausgeführt werden, der eine Mischung von 32- und 64-Bit-Software in sich selbst nicht zulässt. Abgesehen von Kernel-Treibern gibt es unter aktuellen Betriebssystemen noch User-Mode-Treiber, die dann im Prinzip normale Anwendungssoftware sind und je nach Betriebssystem auch als 32-Bit-Version funktionieren. Für Geräte wie Grafikkarten usw. sind solche Treiber derzeit aber nicht nutzbar. 64-Bit-Kernel-Treiber waren nach der Einführung dieser Betriebssysteme selten und sind es heute für alte, spezielle und seltene Hardware immer noch. Diese Problematik betrifft praktisch hauptsächlich proprietäre Software, weil Hersteller insbesondere bei preiswerten Geräten wie Druckern, Scannern usw. Treiber nicht länger als unbedingt nötig pflegen und normalerweise kein Interesse haben, anderen die Pflege älterer Treiber zu überlassen. Grundsätzlich aber muss auch freie Software an 64-Bit angepasst sein, um korrekt zu funktionieren, mit einer einfachen Neukompilation der Software kann, muss es aber nicht getan sein. Ob eine Software für 64-Bit geeignet ist oder nicht, hängt also vollständig von der Software und nicht direkt ihrem Entwicklungsmodell ab, freie Software hat nur den theoretischen Vorteil, dass sie leichter angepasst werden könnte. Moderne 64-Bit-Betriebssysteme führen Anwendungen, die nur für 32-Bit kompiliert wurden, in aller Regel weiterhin aus, Windows-Systeme z.B. durch WOW64. Ihnen steht aber je nach Anwendung nur maximal 2 bis 4 GiB Speicher zur Verfügung.

Unter 32-Bit-Systemen gibt es mit PSE36 und PAE Möglichkeiten, die 4-GiB-Grenze zu überschreiten (das Limit von 2 GiB oder 4 GiB pro Prozess bleibt aber). Diese Prozessorerweiterungen vergrößern allerdings nur den physisch adressierbaren Speicher, jeder Prozess für sich kann weiterhin nur 4 GiB Daten gleichzeitig adressieren. Unter Microsoft Windows existiert außerdem die Möglichkeit, über eine AWE genannte Schnittstelle physische Speicherseiten jenseits der 4-GiB-Grenze in den logischen Adressraum des Prozesses einzublenden, womit ein 32-Bit-Prozess insgesamt mehr als 4 GiB ansprechen kann. Allerdings erlauben nur einige spezielle Versionen von Windows 2000 und Windows Server 2003 die Verwendung von RAM jenseits der 4-GiB-Grenze auf einem 32-Bit-System; die Verbraucher-Betriebssysteme Windows XP (ab SP2), Windows Vista und Windows 7 erlauben dies in ihren 32-Bit-Versionen gewollt nicht, um Inkompatibilitäten mit diversen Treibern von Fremdfirmen zu vermeiden. Für Normalanwender von Windows bleibt daher nur der Wechsel auf eine 64-Bit-Version des Betriebssystems als Problemlösung.

Weblinks[Bearbeiten]

Einzelnachweise[Bearbeiten]

  1. Virtual Memory in Linux Aaron Hall (Dezember 2002, englisch)
  2. The oft-misunderstood /3GB switch Raymond Chen (2004, englisch)
  3. http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx