Article de reference

Gestion de la mémoire

Gestion manuelle de la mémoire Allocation de blocs de taille fixe Dans ce système, la mémoire est allouée en plusieurs pools au lieu d'un seul. Chaque pool représente des blocs ...

Gestion manuelle de la mémoire
Allocation de blocs de taille fixe

Dans ce système, la mémoire est allouée en plusieurs pools au lieu d'un seul. Chaque pool représente des blocs de mémoire dont la taille est une puissance de deux , ou des blocs d'une autre progression de taille appropriée. Tous les blocs d'une taille donnée sont stockés dans une liste chaînée triée ou un arbre , et tous les nouveaux blocs créés lors de l'allocation sont ajoutés à leur pool respectif pour une utilisation ultérieure. Si la taille demandée est inférieure à celle disponible, le plus petit bloc disponible est sélectionné et divisé. Lorsqu'un bloc est divisé, il est divisé en deux blocs plus petits, chacun devenant un « bâton » unique de l'autre. L'une des parties résultantes est sélectionnée, et le processus se répète jusqu'à ce que la requête soit satisfaite. Lors de l'allocation d'un bloc, l'allocateur commence par le plus petit bloc suffisamment grand afin d'éviter les divisions inutiles. Lorsqu'un bloc est libéré, il est comparé à son bloc « bâton ». S'ils sont tous deux libres, ils sont combinés et placés dans la liste des blocs « bâtons » de taille correspondante.

Répartition par tranche

De nombreux systèmes de type Unix, ainsi que Microsoft Windows, implémentent une fonction permettant ad hoc présente dans de nombreux systèmes mais jamais dans POSIX ni dans la norme C, son comportement en cas de dépassement de capacité de la pile est indéfini.

Une version plus sûre d'alloca, appelée `alloc` gnulib fournit une interface équivalente, mais au lieu de lever une exception SEH en cas de dépassement de capacité, elle délègue à `malloc` lorsqu'une taille excessive est détectée. Une fonctionnalité similaire peut être émulée en utilisant une comptabilité manuelle et une vérification de taille, comme dans les utilisations de `alloc`

Gestion automatisée de la mémoire

La bonne gestion de la mémoire dans une application est un problème complexe, et plusieurs stratégies différentes pour gérer cette mémoire ont été mises au point.

Gestion automatique des variables de la pile d'appels

Le ramasse-miettes est une stratégie permettant de détecter automatiquement la mémoire allouée à des objets devenus inutilisables dans un programme, et de la libérer. Cette méthode s'oppose à la gestion manuelle de la mémoire, où le programmeur définit explicitement les demandes et libérations de mémoire dans le programme. Si le ramasse-miettes automatique présente l'avantage de réduire la charge de travail du programmeur et de prévenir certains types d'erreurs d'allocation de mémoire, il consomme lui-même des ressources mémoire et peut entrer en concurrence avec le programme pour l'utilisation du processeur.

comptage de référence

Un pool de mémoire est une technique de libération automatique de la mémoire en fonction de l'état de l'application, comme le cycle de vie d'une requête ou d'une transaction. L'idée est que de nombreuses applications exécutent de larges blocs de code susceptibles de générer des allocations de mémoire, mais qu'à un certain stade de l'exécution, ces blocs ne sont plus valides. Par exemple, dans un service web, après chaque requête, le service n'a plus besoin de la mémoire allouée lors de son exécution. Par conséquent, plutôt que de surveiller si la mémoire est actuellement utilisée, elle est allouée en fonction de la requête ou de l'étape du cycle de vie à laquelle elle est associée. Une fois cette requête ou étape terminée, toute la mémoire associée est libérée simultanément.

Systèmes à mémoire virtuelle

Gestion de la mémoire dans les systèmes Burroughs/Unisys MCP

Un système d'exploitation gère diverses ressources au sein du système informatique. Le sous-système mémoire est l'élément système chargé de la gestion de la mémoire. Il combine la ressource mémoire matérielle et le logiciel du système d'exploitation qui gère cette ressource.

Le sous-système de mémoire gère la mémoire physique et la mémoire virtuelle du système (toutes deux faisant partie des ressources matérielles). La mémoire virtuelle étend la mémoire physique en utilisant un espace supplémentaire sur un périphérique, généralement un disque. Le sous-système de mémoire est responsable du déplacement du code et des données entre la mémoire principale et la mémoire virtuelle, un processus appelé superposition. Burroughs a été la première implémentation commerciale de la mémoire virtuelle (bien que développée à l'Université de Manchester pour l'ordinateur Ferranti Atlas) et a intégré la mémoire virtuelle à la conception du système du B5000 dès le départ (en 1961), sans nécessiter d' unité de gestion de la mémoire (MMU) externe.

Le sous-système de mémoire est chargé d'associer les requêtes logiques de blocs de mémoire à des portions physiques de mémoire (segments) figurant dans la liste des segments libres. Chaque bloc alloué est géré au moyen d'un descripteur de segment , un mot de contrôle spécial contenant des métadonnées pertinentes sur le segment, notamment son adresse, sa longueur, son type de machine et le bit p (ou bit de présence) qui indique si le bloc se trouve en mémoire principale ou s'il doit être chargé à partir de l'adresse spécifiée dans le descripteur.

Les descripteurs sont essentiels pour garantir la sécurité de la mémoire et empêcher les opérations de débordement ou de sous-débordement du bloc référencé (phénomène communément appelé dépassement de tampon). Les descripteurs sont des mots de contrôle protégés qui ne peuvent être manipulés que par certains éléments spécifiques du système d'exploitation MCP (activés par la directive de bloc UNSAFE dans NEWP ).

Donald Knuth décrit un système similaire dans la section 2.5 « Allocation dynamique de stockage » de « Algorithmes fondamentaux » .

Gestion de la mémoire dans OS/360 et ses successeurs

IBM System/360 ne prend pas en charge la mémoire virtuelle. L'isolation mémoire des travaux peut être réalisée à l'aide de clés de protection , chaque travail se voyant attribuer une clé différente : 0 pour le superviseur ou une valeur comprise entre 1 et 15. La gestion de la mémoire sous OS/360 est une fonction du superviseur . L'espace mémoire est demandé GETMAINet libéré à l'aide de FREEMAINmacros, ce qui entraîne un appel au superviseur ( SVC ) pour exécuter 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 d'une région de travail ou de la zone de file d'attente système partagée (SQA) repose sur des sous-pools , des zones dont la taille est un multiple de 2 Ko – la taille d'une zone protégée par une clé de protection. Les sous-pools sont numérotés de 0 à 255. Au sein d'une région, les sous-pools se voient attribuer soit la protection de stockage du travail, soit la clé du superviseur (clé 0). Les sous-pools 0 à 127 reçoivent la clé du travail. Initialement, seul le sous-pool 0 est créé et toutes les demandes de stockage utilisateur sont satisfaites à partir de ce sous-pool, sauf si un autre est spécifié dans la demande de mémoire. Les sous-pools 250 à 255 sont créés par les demandes de mémoire du superviseur pour le compte du travail. La plupart d'entre eux se voient attribuer la clé 0, bien que certains reçoivent la clé du travail. La numérotation des sous-pools est également pertinente dans MFT, bien que les détails soient beaucoup plus simples. MFT utilise des partitions fixes redéfinissables par l'opérateur au lieu de régions dynamiques et PCP ne possède qu'une seule partition.

Chaque sous-pool est défini par une liste de blocs de contrôle identifiant les blocs de mémoire alloués et libres au sein de ce sous-pool. La mémoire est allouée soit en trouvant une zone libre de taille suffisante, soit en allouant des blocs supplémentaires dans le sous-pool, jusqu'à la taille de la région de la tâche. Il est possible de libérer tout ou partie d'une zone de mémoire allouée.

Les caractéristiques d' OS/VS1 sont similaires à celles de MFT et de MVT ; celles d' OS/VS2 sont similaires à celles de MVT, à l'exception de la taille des pages, qui est de 4 Kio. Pour OS/VS1 et OS/VS2, la zone de file d'attente système partagée (SQA) n'est pas paginable.

Dans MVS, l'espace d'adressage comprend une zone partagée paginable supplémentaire, la zone de stockage commune (CSA), et deux zones privées supplémentaires : la zone de file d'attente système locale non paginable (LSQA) et la zone de travail système paginable (SWA). De plus, les clés de stockage 0 à 7 sont toutes réservées à l'usage du code privilégié.

Plus d articles de Worldlex Wiki

Revenez a l index pour explorer davantage de pages sur l histoire, la science, la culture, la geographie et la societe en francais.

Explorer l index