Quelles sont les différences entre la mémoire virtuelle et la mémoire physique?

Les logiciels fonctionnent sur le système d'exploitation sur une prémisse très simple-ils nécessitent de la mémoire. Le système d'exploitation de l'appareil le fournit sous la forme de RAM. La quantité de mémoire requise peut varier - Certains logiciels ont besoin d'une mémoire énorme, d'autres nécessitent une mémoire dérisoire. La plupart des utilisateurs (sinon tous) exécutent simultanément plusieurs applications sur le système d'exploitation, et étant donné que la mémoire est coûteuse (et que la taille de l'appareil est finie), la quantité de mémoire disponible est toujours limitée. Donc, étant donné que tous les logiciels nécessitent une certaine quantité de RAM, et tous peut être fait pour fonctionner en même temps, OS doit prendre soin de deux choses:

1. que le logiciel s'exécute toujours jusqu'à ce que l'utilisateur l'abandonne, c'est-à-dire qu'il ne devrait pas s'annuler automatiquement car le système D'exploitation est à court de mémoire.
2. l'activité ci-dessus, tout en maintenant une performance respectable pour les logiciels en cours d'exécution.

Maintenant, la question principale se résume à la façon dont la mémoire est gérée. Qu'est-ce qui régit exactement où dans la mémoire seront les données appartenant à un donné logiciel résident?

Solution Possible 1 : laissez les logiciels individuels spécifier explicitement l'adresse mémoire qu'ils utiliseront dans le périphérique. Supposons que Photoshop déclare qu'il sera toujours utiliser des adresses mémoire, allant de 0 à 1023 (imaginez la mémoire comme un tableau linéaire d'octets, de sorte que le premier octet est à l'emplacement 0, 1024ème octet à l'emplacement 1023) - c'est à dire occupant 1 GB mémoire. De même, VLC déclare qu'il occupera de la mémoire gamme 1244 à 1876, etc.

Avantages:

1. chaque application est pré-assignée à un emplacement mémoire, donc quand elle est installée et exécutée, elle stocke simplement ses données dans cette zone de mémoire, et tout fonctionne bien.

Inconvénients:

1. Cela ne s'échelonne pas. Théoriquement, une application peut nécessiter une énorme quantité de mémoire quand elle fait quelque chose de vraiment lourd. Donc, pour s'assurer qu'il ne manque jamais de mémoire, la zone de mémoire il doit toujours être supérieur ou égal à cette quantité de mémoire. Que se passe-t-il si un logiciel, dont l'utilisation théorique maximale de la mémoire est 2 GB (nécessitant donc une allocation de mémoire 2 GB à partir de la RAM), est installé sur une machine avec seulement 1 GB mémoire? Le logiciel devrait-il simplement abandonner au démarrage, en disant que la RAM disponible est inférieure à 2 GB? Ou devrait-il continuer, et le moment où la mémoire requise dépasse 2 GB, juste abandonner et renflouer avec le message que pas assez de mémoire est disponible?

2. Il n'est pas possible d'empêcher la mutilation de la mémoire. Il y a des millions de logiciels là-bas, même si chacun d'eux était alloué juste 1 kB mémoire, la mémoire totale requise dépasserait 16 GB, ce qui est plus que la plupart des appareils. Comment, alors, différents logiciels peuvent-ils être attribués des emplacements de mémoire qui n'empiètent pas sur les zones de l'autre? Premièrement, il n'y a pas de marché centralisé des logiciels qui puisse réglementer que lorsqu'un nouveau logiciel est publié, il doit s'attribuer autant de mémoire de cette zone encore inoccupée, et d'autre part, même s'il y en avait, il n'est pas possible de le faire parce que le non. de logiciels est pratiquement infinie (nécessitant ainsi une mémoire infinie pour accueillir tous), et la RAM totale disponible sur n'importe quel appareil n'est pas suffisante pour accueillir même une fraction de ce qui est nécessaire, rendant ainsi inévitable l'empiétement des limites de mémoire d'un logiciel sur celle d'un autre. Alors que se passe t il quand Photoshop est attribué emplacements de mémoire 1 à 1023 et VLC est affecté 1000 à 1676? Que faire si Photoshop stocke des données à l'emplacement 1008, puis VLC écrase cela avec ses propres données, et plus tard Photoshop y accède en pensant que ce sont les mêmes données qui y sont stockées précédemment? Comme vous pouvez l'imaginer, de mauvaises choses vont arriver.

Si clairement, comme vous pouvez le voir, cette idée est plutôt naïf.

Solution Possible 2 : essayons un autre schéma - où OS fera la majorité de la gestion de la mémoire. Les logiciels, chaque fois qu'ils ont besoin de mémoire, demanderont simplement le système D'exploitation, et le système d'exploitation s'adaptera en conséquence. Say OS garantit que chaque fois qu'un nouveau processus demande de la mémoire, il allouera la mémoire à partir de l'adresse d'octet la plus basse possible (comme indiqué précédemment, la RAM peut être imaginée comme un tableau linéaire d'octets, donc pour une 4 GB RAM, les adresses plage pour un octet de 0 à 2^32-1) si le processus démarre, sinon s'il s'agit d'un processus en cours d'exécution demandant la mémoire, il allouera à partir du dernier emplacement de mémoire où ce processus réside toujours. Puisque les logiciels émettront des adresses sans tenir compte de l'adresse de mémoire réelle où ces données seront stockées, OS devra maintenir un mappage, par logiciel, de l'adresse émise par le logiciel à l'adresse physique réelle (Note: c'est l'un des deux raisons pour lesquelles nous appelons ce concept Virtual Memory. Les logiciels ne se soucient pas de l'adresse mémoire réelle où leurs données sont stockées, ils crachent simplement des adresses à la volée, et le système d'exploitation trouve le bon endroit pour l'adapter et le trouver plus tard si nécessaire).

Disons que l'appareil vient d'être allumé, que le système d'exploitation vient de lancer, qu'il n'y a pas d'autre processus en cours d'exécution (en ignorant le système d'exploitation, qui est aussi un processus!), et vous décidez de lancer VLC . Donc VLC est alloué une partie de la RAM à partir des adresses d'octets les plus bas. Bien. Maintenant, pendant que la vidéo est en cours d'exécution, vous devez démarrer votre navigateur pour afficher une page Web. Ensuite, vous devez lancer Notepad pour griffonner du texte. Et puis Eclipse pour faire du codage.. Très vite, votre mémoire de 4 GB est tout épuisé, et la RAM ressemble à ceci:

                                   

Problème 1: Maintenant, vous ne pouvez pas commencer tout autre processus, pour tout RAM est utilisé. Ainsi, les programmes doivent être écrits en gardant à l'esprit le maximum de mémoire disponible(pratiquement encore moins sera disponible, car d'autres logiciels fonctionneront parallèlement!). En d'autres termes, vous ne pouvez pas exécuter une application consommant beaucoup de mémoire dans votre PC ramshackle 1 GB.

Donc, maintenant que vous décidez que vous n'avez plus besoin de garder Eclipse et Chrome ouvrir, les fermer afin de libérer de la mémoire. L'espace occupé dans RAM par ces processus est récupéré par OS, et il ressemble à ceci maintenant:

                                    

Supposons que ces deux libère 700 MB de l'espace - (400 + 300) MO. Maintenant, vous devez lancer Opera , qui prendra de l'espace 450 MB. Eh bien, vous avez plus de 450 MB espace disponible au total, but...it n'est pas contigu, il est divisé en morceaux individuels, dont aucun n'est assez grand pour tenir 450 MB. Donc vous avez frappé sur un idée brillante, déplaçons tous les processus ci-dessous vers le plus haut possible, ce qui laissera l'espace vide 700 MB dans un morceau en bas. C'est ce qu'on appelle compaction. Très bien, sauf que...tous les processus qui sont en cours d'exécution. Les déplacer signifiera déplacer l'adresse de tous leurs contenus (rappelez-vous, OS maintient un mappage de la mémoire crachée par le logiciel à l'adresse mémoire réelle. Imaginez que le logiciel avait craché une adresse de 45 avec des données 123, et OS avait stocké dans l'emplacement 2012 et créé une entrée dans la carte, cartographie 45 à 2012. Si le logiciel est maintenant déplacé en mémoire, ce qui était à l'emplacement 2012 ne sera plus à 2012, mais dans un nouvel emplacement, et le système d'exploitation doit mettre à jour la carte en conséquence pour mapper 45 à la nouvelle adresse, de sorte que le logiciel puisse obtenir les données attendues (123) lorsqu'il interroge En ce qui concerne le logiciel, tout ce qu'il sait est que l'adresse 45 contient les données 123!)! Imaginez un processus qui fait référence à une variable locale i. Au moment où il est à nouveau accessible, son adresse a changé, et il ne sera plus en mesure de le trouver. La même chose vaut pour toutes les fonctions, objets, variables, fondamentalement tout a une adresse, et déplacer un processus signifiera changer l'adresse de tous. Ce qui nous conduit à:

Problème 2: Vous ne pouvez pas déplacer un processus. Les valeurs de toutes les variables, fonctions et objets processus ont des valeurs codées en dur comme recraché par le compilateur lors de la compilation, le processus dépend Les étant au même endroit au cours de sa vie, et les Changer est coûteux. La suite, les processus laissent derrière eux de gros "holes " lorsqu'ils sortent. Ceci est appelé External Fragmentation.

Très bien. Supposons en quelque sorte, par une manière miraculeuse, vous parvenez à déplacer les processus vers le haut. Maintenant, il y a 700 MB d'espace libre à la en bas:

                        

Opéra douceur correspond à la partie inférieure. Maintenant, votre RAM ressemble à ceci:

                                    

Bien. Tout est à la recherche d'amende. Cependant, il ne reste plus beaucoup d'espace, et maintenant vous devez lancer Chrome encore une fois, un porc de mémoire connu! Il a besoin de beaucoup de mémoire pour commencer, et vous n'en avez presque plus...Sauf.. vous remarquez maintenant que certains des processus, qui occupaient initialement un grand espace, n'ont plus besoin de beaucoup d'espace. Peut-être que vous avez arrêté votre vidéo dans VLC , par conséquent, il occupe toujours de l'espace, mais pas autant que nécessaire lors de l'exécution d'une vidéo haute résolution. De même pour le bloc-notes et Photos. Votre RAM ressemble maintenant à ceci:

                                        

Holes, une fois de plus! Retour à la case départ un! Sauf, auparavant, les trous se sont produits en raison de la fin des processus, maintenant c'est dû à des processus nécessitant moins d'espace qu'auparavant! Et vous avez le même problème, le holes combiné rendement plus d'espace que nécessaire, mais ils sont dispersés autour de, pas beaucoup d'utilisation dans l'isolement. Vous devez donc déplacer à nouveau ces processus, une opération coûteuse et très fréquente, car les processus réduiront fréquemment leur taille au cours de leur durée de vie.

Problème 3: les processus, au cours de leur durée de vie, peuvent réduire en taille, laissant derrière eux l'espace inutilisé, qui, si nécessaire pour être utilisé, nécessitera l'opération coûteuse de nombreux processus. Ceci est appelé Internal Fragmentation.

Bien, alors maintenant, votre système d'exploitation fait la chose requise, déplace les processus et démarre Chrome et après un certain temps, votre RAM ressemble à ceci:

Cool. Maintenant supposons que vous repreniez à regarder Avatar dans VLC. Son exigence de mémoire va tirer! Mais...il n'y a plus d'espace pour qu'il grandisse, car le bloc-notes est blotti en bas. Donc, encore une fois, tous les processus doivent se déplacer ci-dessous jusqu'à ce que VLC ait trouvé suffisamment d'espace!

Problème 4: Si les processus doivent se développer, ce sera une opération très coûteuse

Très bien. Supposons maintenant que Photos soit utilisé pour charger des photos disque dur externe. L'accès au disque dur vous emmène du domaine des caches et de la RAM à celui du disque, qui est plus lent par ordre de grandeur. Douloureusement, irrévocablement, transcendentalement plus lent. C'est une opération d'E/S, ce qui signifie qu'elle N'est pas liée au processeur (c'est plutôt le contraire), ce qui signifie qu'elle n'a pas besoin d'occuper la RAM en ce moment. Cependant, il occupe toujours la RAM obstinément. Si vous voulez lancer Firefox en attendant, vous ne pouvez pas, car il n'y a pas beaucoup de mémoire disponible, alors que si Photos était sorti de la mémoire pendant la durée de son activité liée aux e/s, il aurait libéré beaucoup de mémoire, suivi d'un compactage (coûteux), suivi de Firefox s'intégrer.

Problème 5: les tâches liées aux E/S continuent d'occuper la RAM, ce qui entraîne une sous-utilisation de la RAM, qui aurait pu être utilisée par les tâches liées au processeur entre-temps.

Donc, comme nous pouvons le voir, nous avons tellement de problèmes même avec l'approche de la mémoire virtuelle.

---

, Il existe deux approches pour s'attaquer à ces problèmes - paging et segmentation. Laissez-nous discuter paging. Dans cette approche, l'espace d'adressage virtuel d'un processus est mappé à la mémoire physique en morceaux - disant pages. Un typique page la taille est 4 kB. Le mappage est maintenu par quelque chose appelé a page table, étant donné une adresse virtuelle, tout ce que nous devons faire maintenant est de savoir qui page l'adresse de la appartenir à, puis de la page table, trouver l'emplacement correspondant pour que page en mémoire physique réelle (connu sous le nom frame), et étant donné que le décalage de l'adresse virtuelle à l'intérieur de la page est de même pour le page ainsi que le frame, trouvez l'adresse réelle en ajoutant que l'offset de l'adresse retournée par la page table. Pour exemple:

À gauche se trouve l'espace d'adressage virtuel d'un processus. Disons que l'espace d'adressage virtuel nécessite 40 unités de mémoire. Si l'espace d'adressage physique (sur la droite) avait aussi 40 unités de mémoire, il aurait été possible de mapper tous les emplacements de la gauche à un emplacement sur la droite, et nous aurions été si heureux. Mais comme la malchance l'aurait, non seulement la mémoire physique a moins (24 ici) d'unités de mémoire disponibles, elle doit l'être partagé entre plusieurs processus ainsi! Fine, nous allons voir comment nous faire avec.

Lorsque le processus démarre, disons qu'une demande d'accès à la mémoire pour l'emplacement 35 est faite. Ici, la taille de la page est 8 (chaque page contient 8 endroits, l'ensemble de l'espace d'adressage virtuel de 40 emplacements contient donc 5 pages). Donc, cet emplacement appartient à la page no. 4 (35/8). Au sein de cette page, cet emplacement a un décalage de 5 (35%8). Si cet emplacement peut être spécifié par le tuple (pageIndex, offset) = (4,3). Ce n'est que le début, donc aucune partie du processus n'est stockée dans la mémoire physique réelle pour le moment. Donc le page table, qui maintient un mappage des pages de gauche vers les pages réelles de droite (où elles sont appelées frames) est actuellement vide. Ainsi, OS abandonne le CPU, permet à un pilote de périphérique d'accéder au disque et de récupérer la page no. 4 pour ce processus (essentiellement un morceau de mémoire du programme sur le disque dont les adresses vont de 32 à 39). Quand il arrive, OS alloue la page quelque part dans la RAM, disons la première image elle-même, et le page table pour ce processus prend note que la page 4 correspond à l'image 0 dans la RAM. Maintenant, les données sont enfin là, dans la mémoire physique. OS interroge à nouveau la table de page pour le tuple (4,3), et cette fois, page table indique que la page 4 est déjà mappée à frame 0 dans la RAM. Donc, OS va simplement à la 0 TH cadre dans la RAM, accède aux données à offset 3 dans ce cadre (prenez un moment pour comprendre cela. L'ensemble de la page, qui a été récupérées à partir du disque, est déplacé vers frame. Donc, quel que soit le décalage d'un emplacement de mémoire individuel dans une page, il sera également le même dans le cadre, puisque dans le page/frame, l'Unité de mémoire réside toujours au même endroit relativement!), et renvoie les données! Parce que les données n'ont pas été trouvées en mémoire à la première requête elle-même, mais plutôt eu être récupérées à partir du disque chargé en mémoire, il constitue un miss.

Très bien. Supposons maintenant qu'un accès mémoire pour l'emplacement 28 soit fait. Il se résume à (3,4). Page table à l'heure actuelle, il n'y a qu'une seule entrée, mappant la page 4 à frame 0. Donc, c'est à nouveau un miss, le processus abandonne le CPU, le pilote de périphérique récupère la page du disque, le processus reprend le contrôle du CPU, et son page table est mis à jour. Dites maintenant la page 3 est mappé à frame 1 dans la RAM. Donc (3,4) devient (1,4), et les données à cet emplacement dans la RAM sont retournées. Bien. De cette façon, supposons que le prochain accès à la mémoire soit pour l'emplacement 8, ce qui se traduit par (1,0). La Page 1 n'est pas encore en mémoire, la même procédure est répétée, et le page est alloué à la trame 2 dans la RAM. Maintenant, le mappage du processus RAM ressemble à l'image ci-dessus. À ce stade, la RAM, qui n'avait que 24 unités de mémoire disponibles, est remplie jusqu'. Supposons que la prochaine demande d'accès à la mémoire pour ce processus provient de l'adresse 30. Elle correspond à (3,6), et page table dit que la page 3 est dans la RAM, et il est associé à l'image 1. Yay!!! Donc, les données sont récupérées à partir de L'emplacement de la RAM (1,6), et retournées. Cela constitue un hit , car les données requises peuvent être obtenues directement à partir de RAM, ce qui est très rapide. De même, les prochaines demandes d'accès, par exemple pour les emplacements 11, 32, 26, 27 tous sont frappe, c'est à dire les données demandées par le processus se trouvent directement dans la RAM sans avoir besoin de regarder ailleurs.

Supposons maintenant qu'une demande d'accès à la mémoire pour l'emplacement 3 arrive. Il se traduit par (0,3), et page table pour ce processus, qui dispose actuellement de 3 entrées, pour les pages 1, 3 et 4 dit que cette page n'est pas dans la mémoire. Comme les cas précédents, il est récupéré à partir du disque, cependant, contrairement aux cas précédents, la RAM est remplie! Alors, que faire maintenant? Ici se trouve la beauté du virtuel mémoire, un cadre de la RAM est expulsé! (Divers facteurs régissent le cadre qui doit être expulsé. Peut être LRU basé, où le cadre qui a été le moins récemment accédé pour un processus doit être expulsé. Peut être first-cum-first-evicted base, où le cadre qui a alloué il y a le plus longtemps, est expulsé, etc. Donc de l'image est expulsé. Dites cadre 1 (juste choisir au hasard). Cependant, que frame est mappé à certains page! (Actuellement, il est mappé par la table de page de notre seul et unique processus de la page 4). Donc, ce processus doit être dit cette nouvelle tragique, celle-là frame, quel malheureux vous appartient, est d'être expulsé de RAM pour faire de la place pour un autre pages. Le processus doit s'assurer qu'il met à jour son page table avec ces informations, c'est-à-dire en supprimant l'entrée pour ce duo de cadres de page, de sorte que la prochaine fois qu'une demande est faite pour cela page, Il dit droit le processus que cette page n'est plus en mémoire, et doit être récupérés à partir du disque. Bien. Ainsi, le cadre 1 est expulsé, la page 0 est introduite et placée dans la RAM, et l'entrée de la page 4 est supprimée et remplacée par la page 0 mappant sur le même cadre 1. Alors maintenant, notre cartographie ressemble à ceci (notez le changement de couleur de la deuxième frame sur le côté droit):

Vu ce qui vient de se passer? Le processus devait se développer, il fallait plus d'espace que la RAM disponible, mais contrairement à notre scénario précédent où chaque processus dans la RAM devait se déplacer pour accueillir un processus en croissance, ici, il est arrivé par un seul page remplacement! Cela a été rendu possible par le fait que la mémoire d'un processus n'a plus besoin d'être contiguë, qu'elle peut résider à différents endroits en morceaux, que le système d'exploitation conserve les informations sur l'endroit où ils se trouvent et, le cas échéant, qu'ils sont interrogés de manière appropriée. Note: vous pourriez penser, hein, et si la plupart du temps c'est un miss, et les données doivent être constamment chargées à partir du disque dans la mémoire? Oui, théoriquement, c'est possible, mais la plupart des compilateurs sont conçus de telle manière que locality of reference, c'est-à-dire que si des données provenant d'un emplacement de mémoire sont utilisées, les données suivantes seront situées dans un endroit très proche, peut-être à partir du même page, le page qui vient d'être chargé en mémoire. En conséquence, la prochaine miss se produira après tout à fait un certain temps, la plupart des besoins de mémoire à venir seront satisfaits par la page qui vient d'être apportée, ou les pages déjà en mémoire qui ont été récemment utilisées. Exactement le même principe nous permet d'expulser le moins récemment utilisé page ainsi, avec la logique que ce qui n'a pas été utilisé pendant un certain temps, n'est pas susceptible d'être utilisé dans un certain temps ainsi. Cependant, il n'est pas toujours le cas, et dans des cas exceptionnels, oui, les performances peuvent souffrir. Plus sur cela plus tard.

Solution pour Problème 4: les processus peuvent maintenant se développer facilement, si un problème d'espace est rencontré, tout ce qu'il faut est de faire un simple page remplacement, sans déplacer aucun autre processus.

---

Solution au problème 1: un processus peut accéder à une mémoire illimitée. Lorsque plus de mémoire que disponible est nécessaire, le disque est utilisé comme sauvegarde, les nouvelles données requises sont chargées en mémoire à partir du disque et les données les moins récemment utilisées frame (ou page) sont déplacées sur le disque. Cela peut aller sur infiniment, et puisque l'espace disque est bon marché et pratiquement illimité, il donne une illusion de mémoire illimitée. Une autre raison pour le nom Virtual Memory, il vous donne l'illusion de la mémoire qui n'est pas vraiment disponible!

Cool. Auparavant, nous étions confrontés à un problème où même si un processus réduit en taille, l'espace vide est difficile à récupérer par d'autres processus (car il nécessiterait un compactage coûteux). Maintenant, il est facile, quand un processus devient plus petit en taille, beaucoup de son pages ne sont plus utilisés, donc quand d'autres processus ont besoin de plus de mémoire, un simple LRU l'expulsion basée expulse automatiquement les moins utilisés pages de RAM, et les remplace par les nouvelles pages des autres processus (et bien sûr mettre à jour le page tables de tous ces processus ainsi que le processus d'origine qui nécessite maintenant moins d'espace), tout cela sans opération de compactage coûteuse!

Solution pour Problème 3: chaque fois que les processus diminuent en taille, leur frames dans la RAM sera moins utilisé, donc une simple expulsion basée sur LRU peut expulser ces pages et les remplacer par pages requis par de nouveaux processus, évitant ainsi Internal Fragmentation sans besoin de compaction.

Quant au problème 2, Prenez un moment pour comprendre cela, le scénario lui-même est complètement supprimé! Il n'est pas nécessaire de déplacer un processus pour s'adapter à un nouveau processus, car maintenant l'ensemble du processus n'a jamais besoin de s'adapter à la fois, seules certaines pages doivent s'adapter ad hoc, cela se produit en expulsant frames de RAM. Tout se passe en unités de pages, Il n'y a donc pas de concept de hole maintenant, et donc pas question de quoi que ce soit en mouvement! Peut-être 10 pages a dû être déplacé en raison de cette nouvelle exigence, il existe des milliers de pages qui sont laissés intacts. Alors que, plus tôt, tous les processus (chaque bit d'entre eux) ont dû être déplacés!

Solution au problème 2: pour s'adapter à un nouveau processus, les données provenant uniquement de parties moins récemment utilisées d'autres processus doivent être expulsées au besoin, et cela se produit dans des unités de taille fixe appelées pages. Il n'y a donc aucune possibilité de hole ou External Fragmentation avec ce système.

Maintenant, lorsque le processus doit effectuer une opération d'E / S, il peut facilement abandonner le processeur! OS expulse simplement tous ses pages de la RAM (peut-être le stocker dans un cache) tout nouveau les processus occupent la RAM entre-temps. Lorsque l'opération d'e / s est terminée, OS restaure simplement ceux pages à la RAM (bien sûr en remplaçant le pages de certains autres processus, peut-être de ceux qui ont remplacé le processus original, ou peut-être de certains qui ont eux-mêmes besoin de faire des E/S maintenant, et peuvent donc abandonner la mémoire!)

Solution au problème 5: Lorsqu'un processus effectue des opérations d'E / S, il peut facilement abandonner L'utilisation de la RAM, ce qui peut être utilisé par d'autres processus. Cela conduit à une utilisation correcte de la RAM.

Et bien sûr, maintenant aucun processus n'accède directement à la RAM. Chaque processus accède à un emplacement de mémoire virtuelle, qui est mappé à une adresse RAM physique et maintenu par le page-table de ce processus. Le mappage est soutenu par le système D'exploitation, le système d'exploitation permet au processus de savoir quel cadre est vide afin qu'une nouvelle page pour un processus puisse y être installée. Puisque cette allocation de mémoire est supervisée par le système d'exploitation lui-même, il peut facilement s'assurer qu'aucun processus n'empiète sur le contenu d'un autre processus en allouant uniquement des trames vides de la RAM, ou en empiétant sur le contenu d'un autre processus dans la RAM, communiquer au processus pour le mettre à jour page-table.

Solution au problème Original: il N'y a aucune possibilité qu'un processus accède au contenu d'un autre processus, puisque l'allocation entière est gérée par le système d'exploitation lui-même, et chaque processus s'exécute dans son propre espace d'adressage virtuel en bac à sable.

Donc paging (entre autres techniques), en conjonction avec la mémoire virtuelle, est ce qui alimente les logiciels d'AUJOURD'hui fonctionnant sur OS-es! Cela libère le développeur du logiciel de se soucier de la quantité de mémoire disponible sur l'appareil de l'utilisateur, où stocker les données, comment empêcher d'autres processus de corrompre les données de leur logiciel, etc. Cependant, il n'est évidemment pas étanches. Il y a défauts:

1. Paging est, en fin de Compte, donnant à l'utilisateur l'illusion d'une mémoire infinie en utilisant le disque comme sauvegarde secondaire. Récupération des données du stockage secondaire pour les intégrer dans la mémoire (appelée page swap, et le cas de ne pas trouver la page désirée dans la RAM est appelé page fault) est cher car il s'agit d'une opération IO. Cela ralentit le processus. Plusieurs de ces échanges de pages se produisent successivement, et le processus devient douloureusement lent. Jamais vu votre logiciel fonctionne bien et dandy, et tout à coup il devient si lent qu'il se bloque presque, ou vous laisse sans option que de le redémarrer? Peut-être trop de swaps de page se produisaient, ce qui le rendait lent (appelé thrashing).

Donc revenir à OP,

Pourquoi avons-nous besoin de la mémoire virtuelle pour exécuter un processus? - comme la réponse l'explique longuement, donner aux logiciels l'illusion de l'appareil / OS ayant une mémoire infinie, de sorte que tout logiciel, grand ou petit, peut être exécuté, sans se soucier de l'allocation de mémoire, ou d'autres processus corrompant ses données, même en cours d'exécution en parallèle. C'est un concept, mis en œuvre dans la pratique à travers diverses techniques, dont l'une, comme décrit ici, est Paging. Il peut également s'agir de Segmentation.

Où se trouve cette mémoire virtuelle lorsque le processus (programme) du disque dur externe est amené à la mémoire principale (mémoire physique) pour l'exécution? - La mémoire virtuelle ne se trouve nulle part en soi, c'est une abstraction, toujours présente, lorsque le Logiciel/Processus/programme est démarré, une nouvelle table de page est créée pour cela, et elle contient le mappage des adresses crachées par ce processus à l'adresse physique réelle en RAM. Puisque les adresses crachées par le processus ne sont pas de vraies adresses, dans un sens, elles sont, en fait, ce que vous pouvez dire, the virtual memory.

Qui prend soin de la mémoire virtuelle et quelle est la taille de la mémoire virtuelle? - Il est pris en charge par, en tandem, le système D'exploitation et le logiciel. Imaginez une fonction dans votre code (qui a finalement compilé et transformé en exécutable qui a engendré le processus) qui contient une variable locale-un int i. Lorsque le code s'exécute, i obtient une adresse de mémoire dans la pile de la fonction. Cette fonction est elle-même stockée comme un objet ailleurs. Ces adresses sont générées par le compilateur (le compilateur qui a compilé votre code dans l'exécutable) - adresses virtuelles. Lorsqu'il est exécuté, i doit résider quelque part dans l'adresse physique réelle pour la durée de cette fonction au moins (à moins qu'il ne s'agisse d'une variable statique!), donc OS mappe l'adresse virtuelle générée par le compilateur de i dans une adresse physique réelle, de sorte que chaque fois que, dans cette fonction, un code nécessite la valeur de i, ce processus peut interroger le système d'exploitation pour cette adresse virtuelle, et le système d'exploitation peut à son tour interroger le adresse physique pour la valeur stockée, et le renvoyer.

Supposons que si la taille de la RAM est de 4 Go (c'est-à-dire 2^32-1 espaces d'adressage), Quelle est la taille de la mémoire virtuelle? - la taille de la RAM n'est pas liée à la taille de la mémoire virtuelle, elle dépend du système d'exploitation. Par exemple, sur Windows 32 bits, il est 16 TB, sur Windows 64 bits, il est 256 TB. Bien sûr, il est également limitée par la taille du disque, puisque c'est là où la mémoire est sauvegardée.

Je copie sans vergogne les extraits de la page de manuel du Haut

VIRT -- Image virtuelle (Ko) La quantité totale de mémoire virtuelle utilisée par la tâche. Il comprend tout le code, les données et les bibliothèques partagées ainsi que les pages qui ont été permuté et les pages qui ont été mappées mais non utilisées.

SWAP -- taille échangée (Ko) Mémoire qui n'est pas résidente mais qui est présente dans une tâche. C'est la mémoire qui a été échangée mais pourrait inclure supplémentaire, non- résident de mémoire. Cette colonne est calculée en soustrayant la mémoire physique de la mémoire virtuelle

Voir ici: Mémoire physique Vs mémoire virtuelle

La mémoire virtuelle est stockée sur le disque dur et est utilisée lorsque la RAM est remplie. La mémoire physique est limitée à la taille des puces RAM installées dans l'ordinateur. La mémoire virtuelle est limitée par la taille du disque dur, de sorte que la mémoire virtuelle a la capacité pour plus de stockage.