Gestion de la mémoire

La gestion de la mémoire est une forme de gestion des ressources appliquée à la mémoire de l’ordinateur . L’exigence essentielle de la gestion de la mémoire est de fournir des moyens d’allouer dynamiquement des portions de mémoire aux programmes à leur demande, et de la libérer pour la réutiliser lorsqu’elle n’est plus nécessaire. Ceci est essentiel pour tout système informatique avancé où plusieurs processus peuvent être en cours à tout moment. ^[1]

Plusieurs méthodes ont été conçues pour augmenter l’efficacité de la gestion de la mémoire. Les systèmes de mémoire virtuelle séparent les adresses mémoire utilisées par un processus des adresses physiques réelles, permettant la séparation des processus et augmentant la taille de l’ espace d’adressage virtuel au-delà de la quantité de RAM disponible en utilisant la Pagination ou le basculement vers le Stockage secondaire . La qualité du gestionnaire de mémoire virtuelle peut avoir un effet important sur les performances globales du système .

Dans certains systèmes d’exploitation , par exemple OS/360 et successeurs , ^[2] la mémoire est gérée par le système d’exploitation. ^{[note 1]} Dans d’autres systèmes d’exploitation, par exemple les systèmes d’ exploitation de type Unix, la mémoire est gérée au niveau de l’application.

La gestion de la mémoire au sein d’un espace d’adressage est généralement classée comme gestion manuelle de la mémoire ou gestion automatique de la mémoire .

Gestion manuelle de la mémoire

Un exemple de fragmentation externe

La tâche de répondre à une demande d’allocation consiste à localiser un bloc de mémoire inutilisé de taille suffisante. Les demandes de mémoire sont satisfaites en allouant des portions d’un grand pool ^{[note 2]} de mémoire appelé tas ou magasin libre . ^{[note 3]} À tout moment, certaines parties du tas sont utilisées, tandis que d’autres sont “libres” (inutilisées) et donc disponibles pour de futures allocations.

Plusieurs problèmes compliquent la mise en œuvre, comme la fragmentation externe , qui survient lorsqu’il existe de nombreux petits écarts entre les blocs de mémoire alloués, ce qui invalide leur utilisation pour une demande d’allocation. Les métadonnées de l’allocateur peuvent également gonfler la taille des petites allocations (individuellement). Ceci est souvent géré par segmentation . Le système de gestion de la mémoire doit suivre les allocations en attente pour s’assurer qu’elles ne se chevauchent pas et qu’aucune mémoire n’est jamais « perdue » (c’est-à-dire qu’il n’y a pas de « fuites de mémoire »).

Efficacité

L’algorithme d’allocation de mémoire dynamique spécifique mis en œuvre peut avoir un impact significatif sur les performances. Une étude menée en 1994 par Digital Equipment Corporation illustre les frais généraux impliqués pour une variété d’allocateurs. La longueur de chemin d’instruction moyenne la plus faible requise pour allouer un seul emplacement de mémoire était de 52 (mesurée avec un profileur de niveau d’instruction sur une variété de logiciels). ^[1]

Implémentations

Étant donné que l’emplacement précis de l’allocation n’est pas connu à l’avance, la mémoire est accessible indirectement, généralement via une référence de pointeur . L’algorithme spécifique utilisé pour organiser la zone mémoire et allouer et désallouer des morceaux est lié au noyau et peut utiliser l’une des méthodes suivantes :

Allocation de blocs de taille fixe

L’allocation de blocs de taille fixe, également appelée allocation de pool de mémoire, utilise une liste libre de blocs de mémoire de taille fixe (souvent tous de la même taille). Cela fonctionne bien pour les systèmes embarqués simples où aucun objet volumineux n’a besoin d’être alloué, mais souffre de fragmentation , en particulier avec de longues adresses mémoire. Cependant, en raison de la surcharge significativement réduite, cette méthode peut considérablement améliorer les performances des objets nécessitant une allocation/désallocation fréquente et est souvent utilisée dans les Jeux vidéo .

Blocs de copain

Dans ce système, la mémoire est allouée à plusieurs pools de mémoire au lieu d’un seul, où chaque pool représente des blocs de mémoire d’une certaine puissance de deux , ou des blocs d’une autre progression de taille pratique. Tous les blocs d’une taille particulière sont conservés dans une liste ou un arbre chaîné triéet tous les nouveaux blocs qui sont formés lors de l’allocation sont ajoutés à leurs pools de mémoire respectifs pour une utilisation ultérieure. Si une taille plus petite que celle disponible est demandée, la plus petite taille disponible est sélectionnée et divisée. L’une des pièces résultantes est sélectionnée et le processus se répète jusqu’à ce que la demande soit terminée. Lorsqu’un bloc est alloué, l’allocateur commencera par le plus petit bloc suffisamment grand pour éviter de casser inutilement des blocs. Lorsqu’un bloc est libéré, il est comparé à son copain. S’ils sont tous les deux gratuits, ils sont combinés et placés dans la liste de blocs d’amis de taille correspondante.

Affectation des dalles

Ce mécanisme d’allocation de mémoire préalloue des blocs de mémoire adaptés pour s’adapter à des objets d’un certain type ou d’une certaine taille. ^[3] Ces blocs sont appelés caches et l’allocateur n’a qu’à suivre une liste d’emplacements de cache libres. La construction d’un objet utilisera l’un des emplacements de cache libres et la destruction d’un objet ajoutera un emplacement à la liste des emplacements de cache libres. Cette technique atténue la fragmentation de la mémoire et est efficace car il n’est pas nécessaire de rechercher une portion de mémoire appropriée, car n’importe quel emplacement ouvert suffira.

Allocation de pile

De nombreux systèmes de type Unix ainsi que Microsoft Windows implémentent une fonction appelée allocapour allouer dynamiquement la mémoire de la pile d’une manière similaire à celle basée sur le tas malloc. Un compilateur le traduit généralement en instructions en ligne manipulant le pointeur de pile. ^[4] Bien qu’il ne soit pas nécessaire de libérer manuellement la mémoire allouée de cette façon puisqu’elle est automatiquement libérée au retour de la fonction appelée alloca, il existe un risque de débordement. Et comme alloca est une extension ad hoc vue dans de nombreux systèmes mais jamais dans POSIX ou dans le standard C, son comportement en cas de débordement de pile n’est pas défini.

Une version plus sûre d’alloca appelée _malloca, qui signale les erreurs, existe sur Microsoft Windows. Cela nécessite l’utilisation de _freea. ^[5] gnulib fournit une interface équivalente, bien qu’au lieu de lancer une exception SEH en cas de débordement, il délègue à malloc lorsqu’une taille trop grande est détectée. ^[6] Une fonctionnalité similaire peut être émulée en utilisant la comptabilité manuelle et la vérification de la taille, comme dans les utilisations de la alloca_accountglibc. ^[7]

Gestion automatique de la mémoire

Dans de nombreuses implémentations de langage de programmation, l’environnement d’exécution du programme alloue automatiquement de la mémoire dans la pile d’appels pour les variables locales non statiques d’un sous- programme , appelées variables automatiques , lorsque le sous-programme est appelé, et libère automatiquement cette mémoire lorsque le sous-programme est quitté. Des déclarations spéciales peuvent permettre aux variables locales de conserver des valeurs entre les invocations de la procédure, ou peuvent permettre l’accès aux variables locales par d’autres sous-programmes. L’allocation automatique des variables locales rend la récursivité possible, à une profondeur limitée par la mémoire disponible.

Collecte des ordures

Le nettoyage de la mémoire est une stratégie permettant de détecter automatiquement la mémoire allouée aux objets qui ne sont plus utilisables dans un programme et de restituer cette mémoire allouée à un pool d’emplacements de mémoire libres. Cette méthode s’oppose à la gestion “manuelle” de la mémoire où un programmeur code explicitement les demandes de mémoire et les libérations de mémoire dans le programme. Bien que la récupération de place automatique ait l’avantage de réduire la charge de travail du programmeur et d’empêcher certains types de bogues d’allocation de mémoire, la récupération de place nécessite ses propres ressources mémoire et peut concurrencer le programme d’application pour le temps processeur.

Systèmes avec mémoire virtuelle

La mémoire virtuelle est une méthode de découplage de l’organisation de la mémoire du matériel physique. Les applications fonctionnent en mémoire via des adresses virtuelles . Chaque tentative par l’application d’accéder à une adresse de mémoire virtuelle particulière entraîne la conversion de l’adresse de mémoire virtuelle en une adresse physique réelle . ^[8] De cette manière, l’ajout de mémoire virtuelle permet un contrôle granulaire des systèmes de mémoire et des méthodes d’accès.

Dans les systèmes de mémoire virtuelle, le système d’exploitation limite la façon dont un processus peut accéder à la mémoire. Cette fonctionnalité, appelée protection de la mémoire , peut être utilisée pour interdire à un processus de lire ou d’écrire dans la mémoire qui ne lui est pas allouée, empêchant ainsi le code malveillant ou défectueux d’un programme d’interférer avec le fonctionnement d’un autre.

Même si la mémoire allouée à des processus spécifiques est normalement isolée, les processus doivent parfois pouvoir partager des informations. La mémoire partagée est l’une des techniques les plus rapides de communication inter-processus .

La mémoire est généralement classée par taux d’accès dans le stockage principal et le Stockage secondaire . Les systèmes de gestion de la mémoire, entre autres opérations, gèrent également le déplacement des informations entre ces deux niveaux de mémoire.

Gestion de la mémoire sous OS/360 et successeurs

IBM System/360 ne prend pas en charge la mémoire virtuelle. ^{[note 4]} L’isolement de la mémoire des travaux est éventuellement réalisé à l’aide de clés de protection , en attribuant au stockage pour chaque travail une clé différente, 0 pour le superviseur ou 1–15. La gestion de la mémoire dans OS/360 est une fonction de superviseur . Le stockage est demandé à l’aide de la GETMAINmacro et libéré à l’aide de la FREEMAINmacro, ce qui entraîne un appel au superviseur ( SVC ) pour effectuer l’opération.

Dans OS/360, les détails varient en fonction de la manière dont le système est généré , par exemple pour PCP , MFT , MVT .

Dans OS/360 MVT, la sous-allocation au sein de la région d’un travail ou de la zone de file d’attente système (SQA) partagée est basée sur des sous- pools , des zones d’une taille multiple de 2 Ko, c’est-à-dire la taille d’une zone protégée par une clé de protection. Les sous-groupes sont numérotés de 0 à 255. ^[9]Au sein d’une région, les sous-pools sont affectés soit à la protection de stockage du travail, soit à la clé du superviseur, la clé 0. Les sous-pools 0 à 127 reçoivent la clé du travail. Initialement, seul le sous-pool zéro est créé et toutes les demandes de stockage utilisateur sont satisfaites à partir du sous-pool 0, sauf si un autre est spécifié dans la demande de mémoire. Les sous-groupes 250 à 255 sont créés par des demandes de mémoire par le superviseur au nom du travail. La plupart d’entre eux se voient attribuer la clé 0, bien que quelques-uns obtiennent la clé du travail. Les numéros de sous-groupe sont également pertinents dans MFT, bien que les détails soient beaucoup plus simples. ^[10] MFT utilise des partitions fixes redéfinissables par l’opérateur au lieu de régions dynamiques et PCP n’a qu’une seule partition.

Chaque sous-groupe est mappé par une liste de blocs de contrôle identifiant les blocs de mémoire alloués et libres dans le sous-groupe. La mémoire est allouée en trouvant une zone libre de taille suffisante, ou en allouant des blocs supplémentaires dans le sous-pool, jusqu’à la taille de la région du travail. Il est possible de libérer tout ou partie d’une zone mémoire allouée. ^[11]

Les détails pour OS/VS1 sont similaires ^[12] à ceux de MFT et de MVT ; les détails pour OS/VS2 sont similaires à ceux de MVT, sauf que la taille de la page est de 4 KiB. Pour OS/VS1 et OS/VS2, la zone de file d’attente système partagée (SQA) ne peut pas être paginée.

Dans MVS , l’espace d’adressage comprend une zone partagée paginable supplémentaire, la zone de stockage commune (CSA), et une zone privée supplémentaire, la zone de travail système (SWA). De plus, les clés de stockage 0-7 sont toutes réservées à une utilisation par code privilégié.

Voir également

• Tableau dynamique
• Collecte des déchets (informatique)
• Mémoire insuffisante
• Gestion de la mémoire basée sur la région

Remarques

1. ^ Cependant, l’environnement d’exécution d’un processeur de langage peut subdiviser la mémoire acquise dynamiquement à partir du système d’exploitation, par exemple pour implémenter une pile.
2. ^ Dans certains systèmes d’exploitation, par exemple, OS/360 , le stockage libre peut être subdivisé de différentes manières, par exemple, sous-pools dans OS/360 , sous la ligne, au-dessus de la ligne et au-dessus de la barre dans z/OS .
3. ^ À ne pas confondre avec lastructure de données de tas non liée.
4. ^ Sauf sur le modèle 67

Références

1. ^ ^{un b} Detlefs, D.; Dosser, A.; Zorn, B. (juin 1994). “Coûts d’allocation de mémoire dans les grands programmes C et C++” (PDF) . Logiciel : pratique et expérience . 24 (6): 527–542. CiteSeerX 10.1.1.30.3073 . doi : 10.1002/spe.4380240602 . S2CID 14214110 .
2. ^ “Allocation de stockage principale” (PDF) . IBM Operating System/360 Concepts and Facilities (PDF) . Bibliothèque de référence des systèmes (première éd.). Société IBM. 1965. p. 74 . Récupéré le 3 avril 2019 .
3. ^ Silberschatz, Abraham ; En ligneGalvin, Peter B. (2004). Notions de système d’exploitation . Wiley. ISBN 0-471-69466-5.
4. ^ alloca(3) – Manuel du programmeur Linux – Fonctions de la bibliothèque
5. ^ “_malloca” . Documentation Microsoft CRT .
6. ^ “gnulib/malloca.h” . GitHub . Récupéré le 24 novembre 2019 .
7. ^ “glibc/include/alloca.h” . Miroirs de Beren Minor. 23 novembre 2019.
8. ^ Tanenbaum, Andrew S. (1992). Systèmes d’exploitation modernes . Falaises d’Englewood, New Jersey : Prentice-Hall. p. 90. ISBN 0-13-588187-0.
9. ^ OS360Sup , pp. 82 -85.
10. ^ OS360Sup , p. 82 .
11. ^ IBM Corporation (mai 1973). Logique du programme : IBM System/360 Operating System MVT Supervisor (PDF) . p. 107–137 . Récupéré le 3 avril 2019 .
12. ^ OSVS1Dig , pp. 2.37 -2.39, Sous-pools de stockage VS1.erreur sfn : pas de cible : CITEREFOSVS1Dig ( aide )

OS360Sup OS Release 21 IBM System/360 Operating System Supervisor Services and Macro Instructions (PDF) . Bibliothèque de référence des systèmes (huitième éd.). IBM. Septembre 1974. GC28-6646-7. OSVS1Dig Résumé de référence du programmeur OS/VS1 version 6 (PDF) . Systems (sixième éd.). IBM. Novembre 1975. GC24-5091-5.

Lectures complémentaires

• Donald Knuth . Algorithmes fondamentaux , troisième édition. Addison-Wesley, 1997. ISBN 0-201-89683-4 . Section 2.5 : Allocation de stockage dynamique, pp. 435–456.
• Algorithmes d’allocation de mémoire simples archivés le 5 mars 2016 sur la Wayback Machine (publiés à l’origine sur la communauté OSDEV)
• Wilson, relations publiques ; Johnstone, MS; Neely, M.; Boles, D. (1995). “Allocation de stockage dynamique : une enquête et un examen critique”. Gestion de la mémoire . Notes de cours en informatique. Vol. 986. pp. 1–116. CiteSeerX 10.1.1.47.275 . doi : 10.1007/3-540-60368-9_19 . ISBN 978-3-540-60368-9.
• Berger, éd. ; Zorn, BG; McKinley, KS (juin 2001). “Composition d’allocateurs de mémoire hautes performances” (PDF) . Actes de la conférence ACM SIGPLAN 2001 sur la conception et l’implémentation des langages de programmation . PLDI ’01. p. 114–124. CiteSeerX 10.1.1.1.2112 . doi : 10.1145/378795.378821 . ISBN 1-58113-414-2. S2CID 7501376 .
• Berger, éd. ; Zorn, BG; McKinley, KS (novembre 2002). “Reconsidérer l’allocation de mémoire personnalisée” (PDF) . Actes de la 17e conférence ACM SIGPLAN sur la programmation, les systèmes, les langages et les applications orientés objet . OUPSLA ’02. p. 1–12. CiteSeerX 10.1.1.119.5298 . doi : 10.1145/582419.582421 . ISBN 1-58113-471-1. S2CID 481812 .
• Wilson, Paul R.; Johnstone, Mark S.; Neely, Michael ; Boles, David (28-29 septembre 1995), Dynamic Storage Allocation: A Survey and Critical Review (PDF) , Austin, Texas: Department of Computer Sciences University of Texas , récupéré le 03/06/2017

Liens externes

Wikibooks a plus sur le thème de: Gestion de la mémoire

• Bibliothèque C++ “Generic Memory Manager”
• Exemple d’allocateur de mémoire d’arène bitmap en C
• TLSF : un répartiteur de temps constant pour les systèmes temps réel
• Diapositives sur l’allocation de mémoire dynamique
• À l’intérieur d’un répartiteur de stockage
• La référence de gestion de la mémoire

• La référence de gestion de la mémoire, allocation du guide du débutant

• Gestion de la mémoire Linux
• Gestion de la mémoire pour les programmeurs système Archivé le 10/05/2012 sur la Wayback Machine
• VMem – malloc général/remplacement gratuit. Allocateur C++ sécurisé pour les threads rapides
• Mémoire dynamique dans les systèmes IEC61508
• Gestion de la mémoire du système d’exploitation