Delphi: Référence de gestion de la mémoire virtuelle FastMM?

Question

J'ai eu un problème récemment (voir ma dernière question) qui m'a amené à examiner de plus près la gestion de la mémoire dans mon application Delphi. Après ma première exploration, j'ai deux questions.

J'ai commencé à jouer avec le FastMmusageArker et remarqua ce qui suit. Lorsque j'ouvre un fichier à utiliser par l'application (qui crée également un formulaire, etc.), il existe une différence significative entre la variation de la mémoire virtuelle disponible pour l'application et la variation de la mémoire "FastMM4 allouée".

Tout d'abord, je suis un peu confus par la terminologie: pourquoi y a-t-il une mémoire allouée par FastMM et une mémoire "système-allouée" (et réservée)? Puisque FastMM est le gestionnaire de mémoire, pourquoi le système est-il en charge de l'attribution de la mémoire?

Aussi, comment puis-je obtenir plus de détails sur les objets / structures qui ont été alloués à la mémoire? Le graphique VM n'est utile que dans la monture de la quantité de mémoire qui est "système allouée" "," System réservé "ou" FastMM attribué ", mais il n'y a pas de lien avec les objets réels nécessitant cette mémoire. Est-il possible par exemple d'obtenir un rapport, la mi-exécution, similaire à ce que FastMM génère lors de la fermeture de l'application? FastMM stocke évidemment cette information quelque part. de
de

En tant que bonus pour moi, si les gens peuvent recommander une bonne référence (livre, site Web) sur le sujet, il serait également très apprécié. Il y a des tonnes d'informations sur le net, mais il est généralement très spécifique à des cas et orientés sur des experts.

merci!

PS: Il ne s'agit pas de trouver des fuites, pas de problème là-bas, essayant de mieux comprendre la gestion de la mémoire et être préventive pour l'avenir, car notre application utilise de plus en plus de mémoire.

Answer 1

Certaines de vos questions sont faciles. Eh bien, l'un d'entre eux quand même!

Pourquoi y a-t-il un peu de fastmm-alloué? la mémoire et certains "système alloué" (et réservé) mémoire? Depuis Fastmm est le gestionnaire de mémoire, pourquoi le système est-il en charge de l'attribution de certaines des mémoire?

Le code que vous écrivez à Delphi n'est qu'une partie de ce qui fonctionne dans votre processus. Vous utilisez des bibliothèques de 3e parties sous la forme de DLL, notamment l'API Windows. Chaque fois que vous créez un formulaire Delphi, par exemple, il y a beaucoup d'objets Windows derrière celui qui consomment de la mémoire. Cette mémoire n'est pas allouée par FastMM et je présume que ce qui est appelé "système alloué" dans votre question.

Cependant, si vous voulez aller plus profond, cela devient très rapidement un sujet extrêmement complexe. Si vous voulez aller plus loin dans la mise en œuvre de la gestion de la mémoire Windows, je pense que vous devez consulter une source de référence sérieuse. Je suggère Windows Internals par Mark Russinovich, David Solomon et Alex Ionescu.

Answer 2

Tout d'abord, je suis un peu confus par la terminologie: pourquoi y a-t-il une mémoire allouée par FastMM et une mémoire "système-allouée" (et réservée)? Puisque FastMM est le gestionnaire de mémoire, pourquoi le système est-il en charge de l'attribution de la mémoire?

Où supposez-vous que FastMM reçoit la mémoire pour allouer? Il vient du système, bien sûr.

Lorsque votre application démarre, FastMM reçoit un bloc de mémoire du système. Lorsque vous demandez une certaine mémoire à utiliser (que ce soit avec getMem, neuf ou tsomething.Create), FastMM tente de vous le donner à partir de ce premier bloc initial. S'il n'y en a pas assez, FastMM demande plus (dans un bloc si possible) du système et le retourne un morceau de cela. Lorsque vous libérez quelque chose, FastMM ne renvoie pas cette mémoire au système d'exploitation, car il figure que vous l'utiliserez à nouveau. Cela le marquait simplement comme inutilisé en interne. Il essaie également de réaligner des blocs inutilisés de manière à ce qu'ils soient aussi contigus que possible, afin d'essayer de ne pas devoir retourner au système d'exploitation pour plus inutilement. (Ce réalignement n'est pas toujours possible, cependant; c'est là que vous vous retrouvez avec une fragmentation de la mémoire des choses comme la résolution multiple de tableaux dynamiques, beaucoup d'objet crée et libère, et ainsi de suite.)

En plus de la mémoire FastMM gère votre application, le système met de la portée de côté pour la pile et le tas. Chaque processus obtient un myritueux d'espace de pile lorsqu'il démarre, car de la place pour mettre des variables. Cette pile (et le tas) peut se développer de manière dynamique au besoin.

Lorsque votre application se déroule, toute la mémoire qu'il est attribuée est libérée au système d'exploitation. (Cela peut ne pas apparaître si immédiatement dans le chef de la tâche, mais c'est.)

est-il possible par exemple d'obtenir un rapport, moyen-exécution, similaire à ce que FastMM génère lors de la fermeture de l'application?

Pas aussi loin que je peux dire. Parce que Fastmm le stocke quelque part ne signifie pas nécessairement qu'il y a un moyen d'y accéder pendant l'exécution de l'extérieur du gestionnaire de mémoire. Vous pouvez regarder la source de FastMmusageRacker pour voir comment les informations sont récupérées (à l'aide de GetMemoryManagerstate et de GetMemoryMap, dans la méthode RefreshSnapshot). La source de FastMM4 est également disponible; Vous pouvez regarder et voir quelles méthodes publiques sont disponibles.

La documentation propre de FastMM (sous la forme des fichiers README, FASTMM4OPTIONS.IV Les commentaires et le fichier FASTMM4_FAQ.TXT) sont utiles dans une certaine mesure pour expliquer comment cela fonctionne et quelles options de débogage (et informations) sont disponibles.

Answer 3

Pour une carte détaillée de quelle mémoire un processus utilise, essayez VMMap à partir de www.sysinternals.com (également co-écrit par Mark Russinovich, mentionné dans la réponse de David).Cela vous permet également de voir ce qui est stocké dans certains des endroits (type Control-T lorsqu'une ligne de détail est sélectionnée).

AVERTISSEMENT: Il y a beaucoup plus de mémoire à utiliser par votre processus que vous pourriez penser.Vous devrez peut-être lire le livre d'abord.