L'allocation dynamique de mémoire en C fait référence à la gestion manuelle de la mémoire pour l'allocation dynamique de mémoire dans le langage de programmation C via un groupe...
Worldlex WikiContenu en francaisLecture gratuite
la gestion manuelle de la mémoire pour l'allocation dynamique de mémoire dans le langage de programmation C via un groupe de fonctions de la bibliothèque standard C , principalement C++ inclut ces fonctions ; cependant, les opérateurs `new` et `delete` offrent des fonctionnalités similaires et sont recommandés par les auteurs de ce langage. Néanmoins, dans certaines situations, l’utilisation de `/` n’est pas appropriée, notamment pour le code de gestion de la mémoire ou le code sensible aux performances, et une combinaison de ` new` et `delete` peut s’avérer nécessaire à la place de l’opérateur de plus haut niveau .langage C gère la mémoire de manière statique , automatique ou dynamique . Les variables statiques sont allouées en mémoire principale, généralement avec le code exécutable du programme, et y restent pendant toute la durée de vie de celui-ci. Les variables automatiques sont allouées sur la pile et leur taille est modifiée lors des appels et retours de fonctions. Pour les variables statiques et automatiques, la taille de l'allocation doit être constante à la compilation (sauf dans le cas des tableaux automatiques de longueur variable ). Si la taille requise n'est connue qu'à l'exécution (par exemple, si des données de taille arbitraire sont lues depuis l'utilisateur ou un fichier disque), l'utilisation d'objets de données de taille fixe est inadéquate.
La durée de vie de la mémoire allouée peut également poser problème. Ni la mémoire à durée statique ni la mémoire à durée automatique ne conviennent à toutes les situations. Les données allouées automatiquement ne sont pas conservées entre plusieurs appels de fonction, tandis que les données statiques persistent pendant toute la durée d'exécution du programme, qu'elles soient nécessaires ou non. Dans de nombreux cas, le programmeur a besoin d'une plus grande flexibilité dans la gestion de la durée de vie de la mémoire allouée.
Ces limitations sont contournées grâce à l'allocation dynamique de mémoire , qui gère la mémoire de manière plus explicite (mais aussi plus flexible), généralement en l'allouant à partir du tas (espace mémoire libre), une zone de mémoire structurée à cet effet. En C, la fonction de bibliothèque `allocate` mallocpermet d'allouer un bloc de mémoire sur le tas. Le programme accède à ce bloc via un pointeur qui mallocrenvoie `null`. Lorsque la mémoire n'est plus nécessaire, le pointeur est passé à ` freedislocate`, qui libère la mémoire afin qu'elle puisse être utilisée à d'autres fins.
La description originale du langage C indiquait que `std::storage` callocet cfree`std::storage` étaient présents dans la bibliothèque standard, mais pas ` std malloc::storage`. Un exemple de code pour une implémentation simple d'un gestionnaire de stockage sous Unix était fourni , utilisant `std::storage` allocet free`std::storage` comme fonctions d'interface utilisateur, et l' sbrkappel système `std::storage` pour demander de la mémoire au système d'exploitation. La documentation Unix de la 6e édition mentionne `std::storage` allocet ` std::storage` freecomme fonctions d'allocation de mémoire de bas niveau. Les routines malloc` freestd::storage` et `std::storage`, dans leur forme moderne, sont décrites en détail dans le manuel Unix de la 7e édition.
Certaines plateformes proposent des appels de fonctions de bibliothèque ou intrinsèques permettant une allocation dynamique à l'exécution à partir de la pile C plutôt que du tas (par exemple alloca() ). Cette mémoire est automatiquement libérée à la fin de l'exécution de la fonction appelante.
Aperçu des fonctions
Les fonctions d'allocation dynamique de mémoire C sont définies dans <stdlib.h>l'en-tête ( <cstdlib>en-tête en C++).
Fonction
Description
tableau de dix entiers avec une portée automatique est simple en C :
tableau de longueur variable (ce qui n'est pas garanti dans toutes les implémentations C11) , on peut allouer un tableau à l'aide de `allocate()` malloc, qui renvoie un pointeur de type `void` (indiquant qu'il s'agit d'un pointeur vers une zone de données de type inconnu), lequel peut être converti par sécurité .
pointeur nommé a(en raison de la syntaxe C, les pointeurs et les tableaux peuvent être utilisés de manière interchangeable dans certaines situations).
Comme mallocil se peut qu'elle ne puisse pas traiter la requête, elle peut renvoyer un pointeur nul ; il est donc recommandé, en programmation, de vérifier ce cas :
" ); return -1 ; }
Lorsque le programme n'a plus besoin du tableau dynamique , il doit finalement appeler freela fonction pour libérer la mémoire qu'il occupe :
initialisée et peut contenir des données résiduelles : des restes de données précédemment utilisées et supprimées. Après une allocation avec malloc, les éléments du tableau sont des variables non initialisées . La commande callocrenverra une allocation déjà effacée.
pointeur void ( void*), ce qui signifie qu'il s'agit d'un pointeur vers une zone de données de type inconnu. L'utilisation d'un transtypage est requise en C++ en raison du système de typage fort, contrairement au C. Il est possible de convertir ce pointeur vers un type spécifique (voir conversion de type ).
des versions antérieures à 1989 qui mallocrenvoyaient initialement un type `T` char*. Par ailleurs, la conversion peut aider le développeur à identifier les incohérences de dimensionnement de type en cas de changement du type du pointeur de destination, notamment si ce pointeur est déclaré loin de l' malloc()appel (bien que les compilateurs et analyseurs statiques modernes puissent signaler ce comportement sans exiger la conversion ).
Cependant, selon la norme C, la conversion de type n'est pas nécessaire, et son ajout peut masquer l'absence de l'en-tête contenant <stdlib.h>le prototype de la fonction malloc. En l'absence de prototype pour `f` malloc, la norme C90 exige que le compilateur C considère que malloc`f` renvoie un `int` int. Si aucune conversion n'est effectuée, C90 exige un diagnostic lors de l'affectation de cet entier au pointeur ; or, avec la conversion, ce diagnostic ne serait pas produit, masquant ainsi un bogue. Sur certaines architectures et certains modèles de données (comme LP64 sur les systèmes 64 bits, où ` longf` et `int` sont codés sur 64 bits et `int` intsur 32 bits), cette erreur peut entraîner un comportement indéfini, car la fonction implicitement déclarée mallocrenvoie une valeur 32 bits alors que la fonction réellement définie renvoie une valeur 64 bits. Selon les conventions d'appel et l'organisation de la mémoire, cela peut provoquer un écrasement de pile . Ce problème a moins de chances de passer inaperçu avec les compilateurs modernes, car C99 n'autorise pas les déclarations implicites ; le compilateur doit donc générer un diagnostic même s'il suppose intune valeur de retour. De plus, si le type du pointeur est modifié lors de sa déclaration, les lignes où la mallocfonction est appelée et où la conversion est effectuée devront également être mises à jour.
En C++, si std::mallocson utilisation est indispensable, il est préférable de static_castl'utiliser plutôt que d'effectuer une conversion brute :
des erreurs de segmentation .
Les erreurs les plus courantes sont les suivantes :
Ne pas vérifier les échecs d'allocation
L'allocation de mémoire n'est pas garantie et peut renvoyer un pointeur nul. Utiliser cette valeur sans vérifier le succès de l'allocation provoque un comportement indéfini . Cela conduit généralement à un plantage (en raison de l'erreur de segmentation résultant de la déréférencement du pointeur nul), mais rien ne garantit qu'un plantage se produira ; s'y fier peut donc également engendrer des problèmes.
fuites de mémoire
L'absence de libération de mémoire freeentraîne l'accumulation de mémoire non réutilisable, qui n'est plus utilisée par le programme. Cela gaspille des ressources mémoire et peut provoquer des échecs d'allocation lorsque ces ressources sont épuisées.pointeur non initialisé ) ou avant un appel à `f` malloc( pointeur non initialisé ), freeun double appel à `f` (« double libération »), etc., provoque généralement une erreur de segmentation et un plantage du programme. Ces erreurs peuvent être transitoires et difficiles à déboguer ; par exemple, la mémoire libérée n’est généralement pas immédiatement récupérée par le système d’exploitation, et les pointeurs non initialisés peuvent donc persister un certain temps et sembler fonctionner.
De plus, en tant qu'interface antérieure à la normalisation ANSI C, POSIX et la spécification Single Unix exigent une gestion correcte des allocations de taille nulle, soit en retournant une valeur toutes les plateformes ne sont pas tenues de respecter ces règles. Parmi les nombreuses erreurs de double libération qu'elle a engendrées, l'exécution de code à distance (RCE) de WhatsApp en 2019 a été particulièrement marquante. Une façon d'encapsuler ces fonctions pour les rendre plus sûres consiste simplement à vérifier les allocations de taille 0 et à les convertir en allocations de taille 1. (Le retour de valeur C++ .
Basé sur le tas
segment de tas . L'allocateur étendait et réduisait généralement le tas pour répondre aux demandes d'allocation.
La méthode du tas souffre de quelques défauts inhérents :
Un allocateur linéaire ne peut se réduire que si la dernière allocation est libérée. Même s'il est largement inutilisé, le tas peut se retrouver « bloqué » à une taille très importante en raison d'une petite allocation persistante à son extrémité, susceptible de gaspiller une quantité considérable d'espace d'adressage. Toutefois, certains allocateurs, sur certains systèmes, peuvent libérer des pages intermédiaires entièrement vides pour le système d'exploitation.
Un allocateur linéaire est sensible à la fragmentation . Un bon allocateur tentera de suivre et de réutiliser les emplacements libres dans l'ensemble du tas, mais lorsque les tailles et les durées d'allocation deviennent mixtes, il peut être difficile et coûteux de trouver ou de fusionner des segments libres suffisamment grands pour accueillir de nouvelles demandes d'allocation.
Un allocateur linéaire présente des caractéristiques de concurrence extrêmement médiocres, car le segment de tas est par processus, chaque thread doit se synchroniser lors de l'allocation, et les allocations concurrentes de threads qui peuvent avoir des charges de travail très différentes amplifient les deux problèmes précédents.
Doug Lea a développé dlmalloc (« Doug Lea's Malloc »), un allocateur de mémoire générique du domaine public , à partir de 1987. La bibliothèque GNU C (glibc) est dérivée de ptmalloc (« pthreads malloc ») de Wolfram Gloger, une version modifiée de dlmalloc intégrant des améliorations liées au multithreading. En novembre 2023, la dernière version de dlmalloc était la version 2.8.6, datant d'août 2012. En 2023, sa licence a été modifiée, passant de CC0 à MIT-0 .
dlmalloc est un allocateur utilisant des étiquettes de limite. La mémoire sur le tas est allouée sous forme de « chunks », des structures de données alignées sur 8 octets contenant un en-tête et de la mémoire utilisable. La mémoire allouée inclut une surcharge de 8 ou 16 octets pour la taille du chunk et les indicateurs d'utilisation (similaire à un vecteur d'annotations ). Les chunks non alloués stockent également des pointeurs vers d'autres chunks libres dans la zone utilisable, ce qui porte la taille minimale d'un chunk à 16 octets sur les systèmes 32 bits et à 24/32 octets (selon l'alignement) sur les systèmes 64 bits.
La mémoire non allouée est regroupée en « compartiments » de tailles similaires, implémentés à l'aide d'une liste doublement chaînée de blocs (avec des pointeurs stockés dans l'espace non alloué à l'intérieur du bloc). Les compartiments sont triés par taille en trois classes :
Pour les requêtes inférieures à 256 octets (requête « smallbin »), un allocateur simple de type « best fit » à deux puissances est utilisé. S'il n'y a pas de blocs libres dans ce bin, un bloc du bin immédiatement supérieur est divisé en deux.
Pour les requêtes de 256 octets ou plus, mais inférieures au seuil de mmap , dlmalloc utilise, depuis la version 2.8.0, un algorithme de trie bit à bit en place (« treebin »). Si l'espace libre est insuffisant pour satisfaire la requête, dlmalloc tente d'augmenter la taille du tas, généralement via l' appel système brk . Cette fonctionnalité a été introduite bien après la création de ptmalloc (à partir de la version 2.7.x) et, par conséquent, ne fait pas partie de glibc, qui hérite de l'ancien allocateur au mieux adapté.
Pour les requêtes dépassant le seuil mmap (une requête « largebin »), la mémoire est toujours allouée à l’aide de l’ appel système mmap . Ce seuil est généralement de 128 Ko. La méthode mmap évite les problèmes liés aux tampons volumineux qui bloquent une petite allocation à la fin après leur expiration, mais alloue toujours une page mémoire entière, qui, sur de nombreuses architectures, a une taille de 4 096 octets.
Le développeur de jeux Adrian Stone soutient que de pagination à la demande . En effet, ses fonctions de rappel de réduction et d'extension du pool ( FreeBSD 7.0 et NetBSD 5.0, l'ancienne mallocimplémentation ( Poul-Henning Kamp ) a été remplacée par jemalloc , écrit par Jason Evans. La principale raison de ce changement était le manque d'évolutivité de jemalloc cœur de processeur . Des expériences mesurant le nombre d'allocations par seconde dans une application multithread ont montré que jemalloc offre une évolutivité linéaire avec le nombre de threads, tandis que pour phkmalloc et dlmalloc, les performances étaient inversement proportionnelles au nombre de threads.
L'implémentation de cette fonction sous OpenBSDmalloc utilise mmap . Pour les requêtes supérieures à une page, l'allocation entière est récupérée à l'aide de mmapmmap ; les tailles inférieures sont allouées à partir de pools de mémoire gérés par mmap, au mallocsein d'un certain nombre de « pages de compartiment », également allouées avec mmap mmap. Lors d'un appel à mmap , la mémoire est libérée et démappée de l' espace d'adressage du processus à l'aide de mmap . Ce système est conçu pour améliorer la sécurité en tirant parti de la randomisation de la disposition de l'espace d'adressage et des pages d'espacement implémentées dans le cadre de l'appel système mmap d'OpenBSD , et pour détecter les bogues d'utilisation après libération : une allocation de mémoire importante étant complètement démappée après sa libération, toute utilisation ultérieure provoque une erreur de segmentation et l'arrêt du programme.munmapmmap
Le projet GrapheneOS a initialement commencé par le portage de l'allocateur de mémoire d'OpenBSD vers la bibliothèque C Bionic d'Android.
espace de stockage local pour les petites allocations. Pour les allocations importantes, on peut utiliser mmap ou sbrk . TCMalloc , une fonction d' allocation de mémoire développée par Google , assure le nettoyage de la mémoire locale des threads inactifs. TCMalloc est considéré comme plus de deux fois plus rapide que ptmalloc de glibc pour les programmes multithreadés
Dans le noyau
Les noyaux des systèmes d'exploitation, tout comme les programmes d'application, doivent allouer de la mémoire. mallocCependant, l'implémentation au sein d'un noyau diffère souvent sensiblement de celle utilisée par les bibliothèques C. Par exemple, les tampons mémoire peuvent être soumis à des restrictions spécifiques imposées par l'accès direct à la mémoire (DMA) , ou la fonction d'allocation de mémoire peut être appelée depuis un contexte d'interruption. Ceci requiert une mallocimplémentation étroitement intégrée au sous-système de mémoire virtuelle du noyau du système d'exploitation.
Surcharge de malloc
Étant donné que mallocles fonctions et leurs homologues peuvent avoir un impact important sur les performances d'un programme, il est fréquent de redéfinir les fonctions d'une application spécifique par des implémentations personnalisées optimisées pour ses schémas d'allocation mémoire. La norme C ne spécifie pas de méthode pour ce faire, mais les systèmes d'exploitation ont trouvé diverses solutions en exploitant la liaison dynamique. L'une d'elles consiste à lier une bibliothèque différente pour redéfinir les symboles. Une autre, utilisée par Unix System V.3 , consiste à créer mallocdes freepointeurs de fonction que l'application peut réinitialiser avec des fonctions personnalisées.
Dans le code source, la fonction peut facilement être remplacée en utilisant des macros de préprocesseur, telles que :
Ces macros sont définies dans un en-tête que tous les fichiers utilisant des fonctions d'allocation de mémoire doivent inclure. Elles doivent également remplacer la fonction `allocate()` strdup, car son résultat est freeaussi transmis à `allocate()`. Les données allouées à l'intérieur des fonctions de la bibliothèque (comme FILEles structures dans ` stdio.hallocate()`) sont toujours traitées directement, sans passer par les wrappers.
La méthode la plus courante sur les systèmes de type POSIX consiste à définir la variable d'environnement LD_PRELOAD avec le chemin de l'allocateur, afin que l'éditeur de liens dynamique utilise cette version de malloc/calloc/free au lieu de l'implémentation de la libc.
Limites de taille d'allocation
La taille maximale des blocs de mémoire mallocpouvant être alloués dépend du système hôte, et plus particulièrement de la taille de la mémoire physique et de l'implémentation du système d'exploitation.
En théorie, la valeur maximale devrait correspondre à la taille maximale d'une zone mémoire, un entier non signé dépendant de l'implémentation. Dans la norme C99 et les versions ultérieures, cette valeur est disponible via la constante `max_size` . Bien que non garantie par size_tà `max_size` .SIZE_MAX<stdint.h>sizeof(size_t)) - 1
Sur les systèmes glibc, le plus grand bloc de mémoire pouvant mallocêtre alloué ne représente que la moitié de cette taille, à savoir . 2^(CHAR_BIT * sizeof(ptrdiff_t) - 1) - 1
On systems that use segmentation, like some memory models under MS-DOS, the largest possible memory block is typically one segment or less and thus significant smaller than the total address space, and size_t might be a smaller type than ptrdiff_t.
Extensions and alternatives
The C library implementations shipping with various operating systems and compilers may come with alternatives and extensions to the standard malloc interface. Notable among these is:
alloca, which allocates a requested number of bytes on the call stack. No corresponding deallocation function exists, as typically the memory is deallocated as soon as the calling function returns. alloca was present on Unix systems as early as 32/V (1978), but its use can be problematic in some (e.g., embedded) contexts. While supported by many compilers, it is not part of the ANSI-C standard and therefore may not always be portable. It may also cause minor performance problems: it leads to variable-size stack frames, so that both stack and frame pointers need to be managed (with fixed-size stack frames, one of these is redundant). Larger allocations may also increase the risk of undefined behavior due to a stack overflow. C99 offered variable-length arrays as an alternative stack allocation mechanismC11 standard.
POSIX defines a function posix_memalign that allocates memory with caller-specified alignment. Its allocations are deallocated with free, so the implementation usually needs to be a part of the malloc library.
Worldlex Wiki