J'écris une application C ++ basée sur QT et je dois être capable de détecter la fragmentation de la mémoire afin de vérifier si le système actuel peut réellement maintenir la charge de la mémoire: le programme Chargez une grosse image (15/21 mégapixels sont la norme) en mémoire puis effectuer un peu de filtrage sur elle (avec des matrices ponctuelles). Par exemple, je possède un problème de fragmentation de la mémoire dans Windows et VMMAP a été très utile dans ce domaine: le problème était de certaines dlls (Wacom Tablet "WinTab32.dll" et l'application Ultramon) ne sont pas déplacées afin de diviser l'espace d'adresses au 0x10000000-0x30000000 VA du processus.
Je tiens à fournir l'application avec une sorte de sensibilisation au problème de la fragmentation et à vous demander si une approche multiplate-forme (Linux / Mac / Win32) donnant aux informations VMMAP donne déjà existant.
3 Réponses :
Réponse courte: il n'y a pas de manière portable.
Réponse plus longue: comment le tas est mis en œuvre et la manière dont il fonctionne est un détail de mise en œuvre de votre implémentation qui diffère largement entre les plates-formes, les bibliothèques STD et les systèmes d'exploitation. Vous devrez créer une version différente pour chaque mise en œuvre - fournie, la mise en œuvre vous donne une API à y accrocher. (Qui je pense devrait être le cas pour les trois plates-formes que vous cible.)
Je pense que vous êtes trop pessimiste. 21 mégapixels, même en supposant une colordepth de 16 bits et un alphaquin de taille égale ne prendrait que 168 Mo. L'espace d'adressage disponible sur un système 32 bits est mesuré en gigaoctets.
Étant donné que la précision est un must, l'image est représentée en mémoire avec des valeurs de flotteur (32bits) et il y a toujours trois canaux (RVB ou CIEAB) menant à 252 Mo, mais ce n'est pas le point. Parfois, l'application commence avec le plus grand bloc attribuable à 1,4 Go, parfois seulement 500 Mo, et les DLL qui provoquent la majeure partie de la fragmentation à la version inférieure VA sont le chargement "winTab32.dll" à 0x10000000. L'espace d'adressage disponible sur les systèmes 32 bits est mesuré dans des gigaoctets, mais peu importe si vous avez 3 Go Total Gratuit en petits morceaux, la fragmentation provoque Bad_alloc sur une machine 4GB-RAM de toute façon ...
Malheureusement, il semble que une fois qu'une DLL soit chargée à 0x10000000, toutes les autres DLL sont transférées à proximité de ce VA: désactivant la tablette WACOM permettent aux autres DLL d'être poussé supérieure, mais chaque fois qu'une limite inférieure utilise, d'autres DLL (telle comme uxtheme.dll) se charger de près.
Si cela ne vous dérange pas de changer la DLL, vous pouvez modifier sa base préférée. 0x10000000 est une mauvaise défaillance particulière de nos jours.
C'est vrai, un choix vraiment pauvre , malheureusement, cette DLL ne peut pas être rebasée (REBASE -V -B 0x10000000 WinTab32.dll dit qu'il ne peut pas être rebasé).
Cela ferait-il ce dont vous avez besoin?
Pas vraiment depuis que je voudrais détecter la situation, bien que «travailler», cela pourrait être très bien fragmenter la mémoire elle-même.
Pour être difficile: l'existence d'un tas est un détail de mise en œuvre, C ++ se référer au magasin libre.
Vous avez raison, mais je l'ai fait exprès depuis que "Heap" semble être un terme beaucoup plus accepté;)
Ce n'est pas seulement une différence de terminologie. Le magasin libre n'a pas besoin d'être un tas du tout. Ce n'est toutefois que la mise en œuvre décide de résoudre des demandes d'allocation de mémoire.