4.3. Concepts �l�mentaires de la m�moire virtuelle
Alors que la technologie soutendant la construction des diff�rentes technologies de stockage modernes soit vraiment impressionnante, il n'est pas n�cessaire que l'administrateur syst�me moyen en connaisse tous les d�tails. En fait, il suffit de garder � l'esprit un seul point, � savoir�:
la RAM n'est jamais assez grande.
Alors que ce truisme puisse au premier abord para�tre humoristique, de nombreux concepteurs de syst�mes d'exploitation ont pass� �norm�ment de temps � essayer de r�duire l'impact de ce manque r�el de m�moire. Ils y sont parvenus gr�ce � la m�moire virtuelle — une mani�re d'associer de la RAM � un stockage lent, afin de donner � un syst�me une m�moire vive plus grande que celle effectivement install�e.
4.3.1. M�moire virtuelle expliqu�e simplement
Commen�ons avec une application hypoth�tique. Le code de l'ordinateur composant cette application a une taille de 10000 octets. Il a �galement besoin de 5000 octets pour le stockage des donn�es et les tampons d'E/S. Dans de telles conditions, l'application ne peut fonctionner que si la RAM dispose d'au moins 15000 octets�; m�me si sa taille est inf�rieure de juste un octet, l'application ne pourra pas tourner.
On fait r�f�rence � ce besoin de 15000 octets sous le terme d'espace d'adressage de l'application. Il correspond au nombre d'adresses uniques n�cessaires pour contenir aussi bien l'application que ses donn�es. Dans les tout premiers ordinateurs, la quantit� de RAM disponible devait �tre sup�rieure � l'espace d'adressage n�cessaire pour faire tourner la plus grande application�; dans le cas contraire, l'ex�cution de l'application �tait vou�e � l'�chec et un message d'erreur apparaissait signalant une "quantit� de m�moire insuffisante".
Une autre approche connue sous le terme d'�crasement (ou overlaying en anglais) a essay� de r�soudre le probl�me en permettant aux programmeurs de sp�cifier les parties de leur application devant �tre en m�moire � tout moment donn�. De la sorte, un code n�cessaire une fois seulement pour les t�ches d'initialisation pouvait �tre �cras� (par superposition) par le code utilis� ult�rieurement. Alors que ce processus a permis de minimiser l'importance des probl�mes li�s au manque de m�moire, sa mise en oeuvre �tait complexe et donnait lieu � de nombreuses erreurs. De plus, ce processus de superposition n'a pas r�ussi � r�soudre le probl�me du manque de m�moire du syst�me en g�n�ral lors de l'exploitation (runtime). En d'autre termes, il est possible qu'au niveau de son ex�cution, un programme aux codes superpos�s n�cessite moins de m�moire qu'un progamme qui ne l'est pas�; mais si le syst�me ne dispose pas d'une m�moire suffisante pour le programme aux codes superpos�s, le r�sultat final demeure le m�me, � savoir un message d'erreur signalant une quantit� de m�moire insuffisante.
La notion de m�moire virtuelle chamboule quelque peu le concept de l'espace d'adressage d'une application. Au lieu de se concentrer sur la quantit� maximale n�cessaire au bon fonctionnement d'une application, un syst�me dot� d'une m�moire virtuelle essaie en permanence d'obtenir une r�ponse � la question inverse�: "quelle est la quantit� minimale de m�moire n�cessaire au bon fonctionnement d'une application�?"
Alors qu'au premier abord, notre application hypoth�tique semble avoir besoin de 15000 octets pour fonctionner correctement, revenez un instant � nos propos de la Section 4.1 — l'acc�s � la m�moire � tendance � s'effectuer de mani�re s�quentielle et localis�e. Dans de telles conditions, la quantit� de m�moire n�cessaire pour ex�cuter l'application � tout moment donn� est inf�rieure � 15000 octets — et bien souvent largement inf�rieure. Prenez par exemple, les types d'acc�s � la m�moire qui sont n�cessaires pour ex�cuter une instruction sur un seul ordinateur�:
La lecture de l'instruction se fait depuis la m�moire.
Les donn�es dont l'instruction a besoin sont lues depuis la m�moire.
Une fois l'instruction ex�cut�e, les r�sultats de cette derni�re sont envoy�s vers la m�moire pour y �tre enregistr�s.
Le nombre sp�cifique d'octets n�cessaires pour chaque acc�s � la m�moire varie selon l'architecture du CPU, l'instruction elle-m�me et le type de donn�es. Toutefois, m�me si une instruction avait besoin de 100 octets de m�moire pour chaque type d'acc�s � la m�moire, les 300 octets n�cessaires sont bien loin du total de 15000 octets requis pour l'espace d'adressage de l'application. S'il existait un moyen d'effectuer un suivi des besoins en m�moire d'une application lors de son ex�cution, il serait possible de la faire tourner en utilisant moins de m�moire que la quantit� exig�e par l'espace d'adressage.
Une question demeure n�anmoins�:
Si une partie seulement de l'application est en m�moire � un moment donn�, o� se trouve le reste�?
4.3.2. M�moire auxiliaire — la pierre angulaire de la m�moire virtuelle
La r�ponse � cette question est courte�: le reste de l'application demeure sur le disque. En d'autres termes, le disque sert de m�moire auxiliaire pour la RAM�; un support de stockage plus lent et plus grand servant de "stockage auxiliaire" pour un support plus rapide et plus petit. Au premier abord, une telle situation pourrait entra�ner un tr�s grand probl�me au niveau de la performance — apr�s tout, les disques durs sont tellement plus lents que la RAM.
Cette remarque est certes valable, mais il est tout � fait possible de maximiser les avantages li�s au comportement d'acc�s s�quentiel et localis� des applications afin d'�liminer la plupart des implications n�gatives associ�es � l'utilisation des disques durs comme m�moire auxiliaire. Pour ce faire, le sous-syst�me de m�moire virtuelle est structur� de telle sorte qu'il essaie de garantir le stockage en m�moire des parties de l'application actuellement requises — ou susceptibles de l'�tre dans le futur proche — seulement pour la dur�e pendant laquelle ces derni�res sont effectivement n�cessaires.
� bien des �gards, cette situation est semblable � la relation existant entre le cache et la RAM�: la combinaison d'une petite quantit� de stockage rapide avec une grande quantit� de stockage lent revient en fait � avoir une grande quantit� de stockage rapide.
Dans cet �tat d'esprit, examinons maintenant en d�tail le processus m�me.
