Merk op dat deze adresruimte bestaat ongeacht hoeveel fysiek geheugen er in uw systeem is ge‹nstalleerd. E‚n van de grote voordelen van de 803836 (in vergelijking met eerdere processors) is dat de processor een omzetting kan doen van een virtueel adres naar een fysiek adres in het RAM van de hardware -- met een klein beetje hulp van het besturingssysteem (in ons geval &os2;), die de processor tabellen moet geven waarin de omzetting gegevens zijn opgeslagen.
Om in staat te zijn om het virtuele geheugen te beheren met in achtname van de diverse processen die op het systeem lopen, verdeelt &os2; de gehele virtuele adresruimte van 4 GB in zogenoemde arena's.
4096 MB -----------------------------------------------------
systeem arena
512 MB -----------------------------------------------------
gedeelde arena
variable ---------------+-----------+---------------
priv‚ | priv‚ | priv‚
arena | arena | arena
proces 1 | proces 2 | proces 23
0 MB -----------------+-----------+---------------
De systeem arena wordt gereserveerd voor code die draait in ring 0,
dat zijn apparatuur stuurprogramma's en de &os2; kernel zelf. Normale applicaties
hebben geen toegang tot dat geheugen.
Daar tegenover staat dat de gedeelde en priv‚ arena's beschikbaar zijn voor het gebruik door applicaties.
Terwijl de systeem en gedeelde arena's altijd worden gedekt door dezelfde fysieke geheugen pagina's, is de priv‚ arena voor ieder proces verschillend. Iedere applicatie heeft zijn eigen priv‚ arena (code en gegevens). Daar tegenover staat dat, de gedeelde arena wordt gebruikt voor code en gegevens die worden gedeeld tussen applicaties: b.v., alle &xwp; Dynamic Link Labraries (DLL's) worden in die arena geladen.
De afbakening tussen gedeelde en priv‚ arena's is variabel en hangt af van de hoeveelheid gedeeld geheugen die door het systeem wordt gebruikt. Daarom loopt het systeem soms "uit het geheugen" als teveel DLL's worden geladen. In werkelijkheid loopt het systeem niet uit het fysieke geheugen (omdat het gewoonlijk het swapbestand vergroot), maar loopt het uit de adresseerbare ruimte.
Alle OS/2 kernels van versie 2.0 tot aan versie 4.5 (de Aurora kernel) hebben een vaste grens van 512 MB geheugen voor applicaties. De reden hiervoor was de ondersteuning van 16-bits applicaties die niet op een eenvouidge wijze toegang hkunnen krijgen tot geheugen boven deze grens.
Dit werd met de Aurora kernel gewijzigd, die applicaties toestaat om geheugen toe te
wijzen boven de 512 MB grens als de VIRTUALADDRESSLIMIT, in de &cfgsys;
opgegeven met een waarde > 512.
De adresseerbare ruimte ziet er dan als volgt uit:
4096 MB ---------------------------------------------
systeem arena
VIRTUALADDRESSLIMIT ------------------------------------
hoog geheugen arena (gedeeld en priv‚)
512 MB ---------------------------------------------
gedeelde arena
variabele -----------------+-----------+---------------
priv‚ | priv‚ | private
arena | arena | arena
proces 1 | proces 2 | proces 23
0 MB ------------------+-----------+--------------
Zoals u ziet, wordt de ruimte tussen de systeem en gedeelde arena's
"hoog geheugen" genoemd en is verdeeld in gedeelde en private arena's.
Dit geheugen wordt alleen maar aan applicaties gegeven als zij er expliciet
naar vragen, dus het inschakelen van hoog geheugen heeft alleen directe
consequenties voor applicaties die zich van die aanwezigheid bewust zijn.
(B.v., Java zal deze arena gebruiken als
SET JAVA_HIGH_MEMORY=1 in de &cfgsys; is opgegeven.)
Echter, het inschakelen van hoog geheugen heeft neven effecten. Zoals hierboven vermeld, dit geheugen kan niet worden gebruikt door 16-bis code. Daarom heeft u de 32-bits TCP/IP implementatie (versie 4.1. of hoger) nodig als u hoog geheugen met Java gebruikt.
Als toevoeging, hoe hoger u de VIRTUALADDRESSLIMIT
instelt, des te kleiner wordt de systeem arena. Daarom zal verhoging van de
virtuele adres limiet het aantal beschikbare processen verminderen