Bibliothèque d'allocation de mémoire hiérarchique pour C ++

Question

Mon application est principalement organisée en couches . J'ai donc constaté que quelque chose comme Les pools de mémoire APR constituent le meilleur moyen.

Tout en lisant sur le SO sur l'emplacement C ++, de nouvelles publications, ici & amp; ici et Une question plus générique d'allocation de C , je pensais à la création manuelle d'un allocateur de pool hiérarchique, comme suggéré dans un message, mais dans la pure tradition de la NYI Je demande d’abord si un tel phénomène existe déjà.

Il pourrait également avoir la propriété intéressante de pouvoir restituer de la mémoire inutilisée au système d'exploitation (dans la mesure où l'attribution pourrait se faire avec mmap (MAP_ANON) ) ou pourrait être allouer de la pile comme suggéré Ferrucico ici .

Answer 1

Je connais un autre bon allocateur de mémoire hiérarchique, mais il appelle malloc sous les couvertures.

  

talloc est un allocateur de mémoire basé sur un pool hiérarchique avec des destructeurs. C’est l’allocateur de mémoire principal utilisé dans Samba4 et a fait une énorme différence dans de nombreux aspects du développement de Samba4.

     

Pour commencer à utiliser talloc, je vous conseillerais de lire le guide de talloc . .

Cela étant dit, le malloc de Glibc utilise déjà mmap (MAP_ANON) pour une allocation supérieure à mmap_threshold , que vous pouvez définir via . mallopt (M_MMAP_THRESHOLD, octets) . Par défaut, il est ajusté dynamiquement entre

/*
  MMAP_THRESHOLD_MAX and _MIN are the bounds on the dynamically
  adjusted MMAP_THRESHOLD.
*/

#ifndef DEFAULT_MMAP_THRESHOLD_MIN
#define DEFAULT_MMAP_THRESHOLD_MIN (128 * 1024)
#endif

#ifndef DEFAULT_MMAP_THRESHOLD_MAX
  /* For 32-bit platforms we cannot increase the maximum mmap
     threshold much because it is also the minimum value for the
     maximum heap size and its alignment.  Going above 512k (i.e., 1M
     for new heaps) wastes too much address space.  */
# if __WORDSIZE == 32
#  define DEFAULT_MMAP_THRESHOLD_MAX (512 * 1024)
# else
#  define DEFAULT_MMAP_THRESHOLD_MAX (4 * 1024 * 1024 * sizeof(long))
# endif
#endif

Attention si vous le baissez; par défaut pas plus de #define DEFAULT_MMAP_MAX 65536 , les morceaux seront alloués avec mmap . Cela peut être changé avec mallopt (M_MMAP_MAX, count) , mais l'utilisation de nombreux mmap a un temps système.

Les variables d'environnement MALLOC_MMAP_THRESHOLD _ , etc. définiront également ces options.

Évidemment, la mémoire que malloc alloue avec mmap est libérée avec munmap . Je ne sais pas si cela est documenté ailleurs que dans le code source de Glibc, ou si aucune garantie de compatibilité n’est garantie.

Answer 2

Les interfaces et implémentations C de Dave Hanson disposent d'un allocateur à pool unique soigneusement réglé. . Vous pouvez les lier pour créer un allocateur hiérarchique, ce qui serait plus simple que de lancer le vôtre à partir de zéro.

Vous avez des résultats de profilage indiquant que la gestion de la mémoire est un goulot d'étranglement important, n'est-ce pas? Ou essayez-vous simplement de simplifier l'API pour l'allocation?