> Tech > Gestion de la mémoire Windows

Gestion de la mémoire Windows

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Comme la plupart des OS modernes, Windows met en oeuvre un système de mémoire virtuelle activé à  la demande. La mémoire virtuelle permet à  l'OS de donner aux applications l'illusion qu'un ordinateur a plus de mémoire physique qu'en réalité.
Sur les systèmes Windows 32 bits, les processus ont un espace

Gestion de la mémoire Windows

d’adresse de mémoire virtuelle
de 4 Go que l’OS divise en principe
à  parts égales entre le processus
et le système. Ainsi, un
processus peut allouer jusqu’à  2 Go de mémoire virtuelle, selon
la quantité disponible. La quantité totale de mémoire virtuelle
allouée à  tous les processus ne peut pas dépasser la
somme des fichiers « paging » du système et de la plus grande
partie de sa mémoire physique (l’OS réserve une petite portion
de mémoire physique).
Compte tenu que les processus peuvent, moyennant un
fichier paging suffisamment grand, allouer une mémoire virtuelle
qui dépasse la capacité de mémoire physique de l’ordinateur,
le sous-système Windows Memory Manager doit
partager la mémoire physique entre les processus et les données
du fichier « caché » de Cache Manager. Comme l’illustre
la figure 1, le Memory Manager attribue à  chaque processus
(Microsoft Word, Nodepad, Windows Explorer, par exemple)
une partie de mémoire physique, appelée ensemble de travail
du processus. Les portions du kernel et des drivers qui
sont paginables, en plus des buffers de mémoire kernel paginables,
appelés pool paginé, et la mémoire physique que
le Cache Manager gère, se voient attribuer leur propre
ensemble de travail, appelé ensemble de travail Système.
Le Memory Manager s’étend et contracte les ensembles
de travail Système et des processus en réponse aux besoins
des processus pour l’accès rapide à  leurs codes et leurs données.
Le matériel de gestion de la mémoire de l’ordinateur
demande que Windows gère les ensembles de travail et la
mémoire virtuelle en blocs de taille page. (Sur des processeurs
x86 32 bits, les pages ont généralement une taille de 4
096 octets. Toutefois, l’OS et les applications gourmandes en
mémoire utilisent aussi de grandes pages de 4 Mo comme
optimisation, quand c’est possible.)
Quand un processus accède à  une page de sa mémoire
virtuelle qui n’est pas présente dans son ensemble de travail,
le processus subit une exception matérielle page fault.
Quand cela se produit, le Memory Manager attribue une
page de mémoire physique disponible pour contenir les
données ayant fait l’objet du nouvel accès. En outre, le
Memory Manager pourrait décider d’étendre l’ensemble de
travail du processus en lui ajoutant la page. Toutefois, si le Memory Manager estime que l’ensemble de travail du processus
est suffisamment grand, il remplacera une page déjà 
dans l’ensemble de travail par la nouvelle page, en choisissant
pour le remplacement la page à  laquelle le processus a
accédé le moins récemment, partant du principe que le
processus a moins de chances d’accéder à  cette page dans un
futur proche.
Quand le Memory Manager supprime une page d’un ensemble
de travail du processus, il doit décider ce qu’il va en
faire. Si la page a été modifiée, le Memory Manager la place
d’abord sur la modified page list, une liste de pages qui pourront
être écrites dans le fichier paging ou
dans les fichiers mappés en mémoire auxquels
les pages correspondent. A partir de
la liste des pages modifiées, le Memory
Manager déplace les pages dans un pool
appelé standby list. Les pages non modifiées
vont directement dans cette liste. On
peut donc considérer que la liste standby
est un cache des données de fichiers.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010