Gestion de la mémoire
Remonter à Gestion de la mémoire - Index
Cette rubrique d'aide décrit les deux gestionnaires de mémoire qui sont utilisés sur les diverses plates-formes cible, et décrit brièvement les problèmes de mémoire liés aux variables.
Sommaire
Gestionnaire de mémoire par défaut
Le gestionnaire de mémoire utilisé est déterminé par la plate-forme/le compilateur cible de votre application.
Le tableau suivant présente la liste des gestionnaires de mémoire par défaut pour chaque plate-forme.
| Plate-forme | Compilateur | Nom du gestionnaire de mémoire |
|---|---|---|
|
Win32 |
FastMM (GETMEM.inc) | |
|
Win64 |
FastMM (GETMEM.inc) | |
|
OSX32 |
Posix/32 | |
|
Linux |
Posix/64 | |
|
iOSDevice32 |
Posix/32 | |
|
iOSDevice64 |
Posix/64 | |
|
iOSSimulator |
Posix/32 | |
|
Android |
Posix/32 |
Le gestionnaire de mémoire FastMM (Win32 et Win64)
Le gestionnaire de mémoire gère toutes les allocations et désallocations de mémoire dynamique d'une application. Les procédures standard New, Dispose, GetMem, ReallocMem et FreeMem System utilisent le gestionnaire de mémoire. Tous les objets, tableaux dynamiques et chaînes longues sont alloués par son intermédiaire.
Pour Win32 et Win64, le gestionnaire de mémoire FastMM par défaut est optimisé pour les applications qui allouent un grand nombre de blocs de taille petite à moyenne, comme c'est habituellement le cas pour les applications orientées objet et celles qui traitent des données chaînes. Le gestionnaire de mémoire est optimisé pour un fonctionnement performant des applications à thread unique ou multithread. D'autres gestionnaires de mémoire, comme les implémentations de GlobalAlloc, LocalAlloc, et la prise en charge du tas privé de Windows, ne fonctionnent généralement pas bien dans ce cas, et entraînent des ralentissements de l'application s'ils sont utilisés directement.
Pour garantir les meilleures performances, le gestionnaire de mémoire s'interface directement avec l'API de mémoire virtuelle (les fonctions >VirtualAlloc et VirtualFree).
Pour Win32, le gestionnaire de mémoire prend en charge jusqu'à 2 Go d'espace d'adressage en mode utilisateur.
Remarque : Pour augmenter l'espace d'adressage du mode utilisateur à 3 Go, voir la rubrique Augmentation de l'espace d'adressage de la mémoire.
Les blocs du gestionnaire de mémoire sont arrondis à une taille représentant un multiple de 4 octets et ils incluent toujours un en-tête de 4 octets dans lequel sont stockés la taille du bloc et d'autres bits de statut. L'adresse de début des blocs de mémoire est toujours alignée sur une frontière d'au moins 8 octets, ou facultativement sur une frontière de 16 octets, ce qui améliore les performances lors de leur adressage. (Voir System.SetMinimumBlockAlignment)
Pour Win64, le gestionnaire de mémoire prend en charge jusqu'à 16 EiB d'espace d'adressage en mode utilisateur, par spéculation.
Remarque : La taille maximale allouable réelle dépend de l'implémentation CPU et du système d'exploitation. Par exemple, l'implémentation Intel/X64 en cours prend en charge jusqu'à 256 TiB (48 bits), et l'implémentation Windows 7 Professionnel prend en charge jusqu'à 192 GiB.
Les blocs du gestionnaire de mémoire sont arrondis à une taille représentant un multiple de 16 octets et ils incluent toujours un en-tête de 8 octets dans lequel sont stockés la taille du bloc et d'autres bits de statut. L'adresse de début des blocs de mémoire est toujours alignée sur une frontière d'au moins 16 octets.
Pour Win32 et Win64, le gestionnaire de mémoire emploie un algorithme qui anticipe les réallocations de blocs à venir, ce qui réduit l'impact sur les performances généralement associé à de telles opérations. L'algorithme de réallocation réduit également la fragmentation de l'espace d'adressage. Le gestionnaire de mémoire fournit un mécanisme de partage qui ne nécessite pas l'utilisation d'une DLL externe.
Le gestionnaire de mémoire comprend des fonctions de génération de rapport afin d'aider les applications à surveiller l'usage de la mémoire et les pertes de mémoire potentielles.
Le gestionnaire de mémoire fournit deux procédures, GetMemoryManagerState et GetMemoryMap, permettant aux applications de récupérer des informations de statut du gestionnaire de mémoire et un plan détaillé de l'utilisation de la mémoire.
Le gestionnaire de mémoire Posix (plates-formes Posix)
Le gestionnaire de mémoire Posix est utilisé lorsque la plate-forme/le compilateur cible est macOS 32, le périphérique iOS 32 bits, le périphérique iOS 64 bits, le simulateur iOS ou Android.
Toutes les fonctions/méthodes de gestion de mémoire utilisent la bibliothèque système Posix, comme indiqué dans le tableau suivant :
| RTL | Fonction POSIX |
|---|---|
Variables
Les variables globales sont allouées dans le segment de données de l'application et persistent pour la durée du programme. Les variables locales (déclarées dans les procédures et les fonctions) sont placées dans la pile d'une application. A chaque appel d'une procédure ou d'une fonction, elle alloue un ensemble de variables locales ; à la sortie, les variables locales sont libérées. Les optimisations du compilateur peuvent libérer des variables encore plus tôt.
Sous Win32, la taille de pile d'une application est définie par deux valeurs : la taille de pile minimale et la taille de pile maximale. Ces valeurs sont contrôlées par les directives de compilation $MINSTACKSIZE et $MAXSTACKSIZE respectivement, par défaut 16 384 (16 Ko) et 1 048 576 (1 Mo). Une application est assurée de disposer de la taille de pile minimale, et la taille de la pile d'une application n'est jamais autorisée à dépasser la taille de pile maximale. S'il n'y a pas assez de mémoire disponible pour satisfaire les besoins de taille minimale de pile d'une application, Windows émettra une erreur lors du démarrage de l'application.
Si une application Win32 nécessite davantage d'espace de la pile que ce qui est spécifié par la taille minimale de pile, de la mémoire supplémentaire est allouée par incréments de 4 Ko. Si l'allocation d'espace pile supplémentaire échoue (car il n'y a plus de mémoire disponible ou parce que la taille totale de la pile dépasserait alors la taille maximale), une exception EStackOverflow est déclenchée. (Les tests de dépassement de la pile sont entièrement automatiques. La directive de compilation $S qui contrôlait à l'origine la vérification des dépassements de pile est conservée uniquement pour la compatibilité ascendante.)
Les variables dynamiques créées avec la procédure GetMem ou New sont allouées sur le tas et persistent tant qu'elles ne sont pas libérées avec FreeMem ou Dispose.
Les chaînes longues, les chaînes étendues, les tableaux dynamiques, les variants et les interfaces sont alloués sur le tas mais leur mémoire est gérée automatiquement.