Profileur de fragmentation de la mémoire

Existe-t-il de bons profileurs de fragmentation de la mémoire? (la version linux gcc serait bien). Valgrind ne peut pas parsingr cela car il utilise des fonctions personnalisées malloc / free.

Merci Andrew

Je commencerais par mtrace . Lorsque vous avez une trace, la glibc est fournie avec un script Perl, mtrace (1), qui détecte les fuites. Cependant, le format de trace est facile à comprendre et doit donc être traité de manière simple dans une parsing de fragmentation.

J’ai bien peur que la réponse soit Valgrind.

Vous pouvez indiquer à Valgrind quelles fonctions sont utilisées pour effectuer des allocations et comment utiliser les extensions valgrind en code (vous devez donc modifier et recomstackr votre application, mais les modifications sont compilées en noops si vous n’êtes pas en train de déboguer), les détails se trouvent dans Valgrind manual Pools de mémoire: travailler avec des allocateurs personnalisés .

Une fois cela fait, vous disposez de deux outils qui vous permettent de diagnostiquer votre utilisation de tas: massif et DHAT (rappel rapide, Valgrind est un ensemble d’outils, il ne fait que lancer celui que nous connaissons et aimons tous, Memcheck, par défaut) .

Massif “est un profileur de tas. Il mesure la quantité de mémoire de tas utilisée par votre programme. Cela inclut à la fois l’espace utile et les octets supplémentaires alloués à des fins de comptabilité et d’alignement. Il peut également mesurer la taille de la (des) stack (s) de votre programme , bien qu’il ne le fasse pas par défaut. ”

Il peut créer des “graphes”, donc c’est un peu graphique:

 19.63 ^ ###                      
      |  #                        
      |  # ::                    
      |  #: :::                 
      |  ::::::::: # #:: ::               
      |  : #::: ::             
      |  : #:::: :::          
      |  : #::::: ::        
      |  ::::::::::: #:::::::     
      |  :: #::::::::   
      |  ::::::: #:::::::: :: 
      |  @@@::: #:::::::: @
      |  :: @:::::::::::: @
      |  :::: @::: #:::::::: @
      |  :::: @::: #::::::: @
      |  ::::: @::: #::::::: @
      |  ::::::: @:::::::::::::
      |  ::::::: @::::::::::::::
      |  ::::::::::::::::::::::::::
      |  ::::::::: @:::::::::::::::
    0 + ---------------------------------------------------- -----------------------> KB 0 29.48

 Nombre d'instantanés: 25
  Instantanés détaillés: [9, 14 (pic), 24]

De plus, il existe un Massif Visualizer qui produit de très jolis graphiques.

DHAT vous permet de diagnostiquer exactement comment l’application utilise son tas, quelles parties sont de courte durée, qui sont conservées pendant toute la durée du programme, mais utilisées uniquement au début, etc. Malheureusement, il ne dispose pas de graphes ni d’outils graphiques utiles avec elle, la sortie est du texte pur. Heureusement, vous pouvez indiquer la quantité de données que vous souhaitez obtenir et la manière de la sortinger afin qu’elle ne soit pas aussi mauvaise que cela en a l’air.

J’ai du mal à comprendre comment un outil que vous pourriez trouver comprendrait les structures de données de segment de votre gestion de mémoire personnalisée. Vous pourrez peut-être obtenir la dissortingbution très chargée (raccordement à malloc / free), mais la dissortingbution gratuite (qui est essentiellement la fragmentation) semble en suspens.

Alors, pourquoi ne pas append des statistiques / histogrammes occupés / libres à votre gestionnaire de mémoire personnalisé. Si les bacs sont indexés par quelque chose de proportionnel à log2 (taille), son O (1) conserve ces statistiques car, lorsque vous divisez et fusionnez, vous connaissez les tailles et vous pouvez trouver le bac par recherche directe en utilisant un index proportionnel à log2 (taille).

par exemple, intervalles d’histogramme

[2 ^ n, 2 ^ (n + 1)) …

(par exemple, si vous voulez des bacs plus fins, utilisez la racine carrée 2 de la base de journal (taille) qui peut être calculée avec 4 instructions entières sur x86 [parsing, comparaison, définition, ajout de bits])

un autre ensemble de tailles de bacs raisonnables à utiliser sont les intervalles d’ouverture suivants

[2 ^ n, 2 ^ n + 2 ^ (n-1)), [2 ^ n + 2 ^ (n-1), 2 ^ (n + 1)) …

à nouveau facilement calculable [balayage de bits, décalage, et append])

nedmalloc est un très bon allocateur personnalisé, livré avec une source, optimisé pour éviter la fragmentation.

Je voudrais le twigr et commencer à regarder sa journalisation interne pour les statistiques de fragmentation.