Gestion de la mémoire sur la plate-forme Win32
Remonter à Gestion de la mémoire - Index
La documentation suivante décrit la gestion de la mémoire sur Win32, et décrit brièvement les problèmes de mémoire des variables.
Le gestionnaire de mémoire (Win32 seulement)
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 utilisent le gestionnaire de mémoire, et tous les objets et chaînes longues sont alloués par son intermédiaire.
Le gestionnaire de mémoire est optimisé pour les applications qui allouent une 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 les opérations performantes des applications à thread unique ou multithread. D'autres gestionnaires de mémoire, tels les implémentations de GlobalAlloc, LocalAlloc, et le support du tas privé de Windows, ne fonctionnent généralement pas bien dans ce cas, et entraînent des chutes de vitesse 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 de Win32 (les fonctions >VirtualAlloc et VirtualFree). Le gestionnaire de mémoire supporte jusqu'à 4 Go d'espace d'adressage en mode utilisateur.
Les blocs du gestionnaire de mémoire sont toujours 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ées la taille du bloc et d'autres bits de statut. L'adresse de début des blocs 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.
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 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.
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 de l'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 minimum et la taille de pile maximum. Ces valeurs sont contrôlées par les directives de compilation $MINSTACKSIZE et $MAXSTACKSIZE qui valent, respectivement, par défaut 16 384 (16 Ko) et 1 048 576 (1 Mo). Une application a la certitude de disposer de la taille de pile minimum et la taille de la pile n'est jamais autorisée à dépasser la taille de pile maximum. S'il n'y a pas assez de mémoire disponible pour satisfaire les besoins minimum 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 minimum de pile, de la mémoire supplémentaire est allouée par incréments de 4 Ko. Si l'allocation des zones supplémentaires de pile é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 maximum), 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.