Ecrire un gestionnaire de mémoire rapide et intelligent - Page 2

Il existe différentes techniques d'allocation, selon ce que tu fais au juste, pour optimiser l'usage de la mémoire dans ton programme. Entre autres :

=> Travailler sur plusieurs blocs mémoire (typiquement avec du mmap). Ca limite la fragmentation, surtout si tu ajoutes des contraintes du type "ce bloc est uniquement pour les allocations de taille X à Y".

=> Ne pas allouer exactement les tailles demandées. Par exemple arrondir au multiple de X supérieur. Ca limite la granularité de la fragmentation.

=> Ne pas faire des allocations à outrance. D'autant plus qu'une allocation mémoire est une opération très lente (encore plus dans un programme threadé). La plupart des programmes bien faits utilisent des algos pas trop cons. Typiquement, quand tu utilises un std::string ou un std::vector, la taille est modifiée par puissances de deux (quand il a besoin de davantage de place, il double la zone réservée). Algorithmiquement, ça donne une efficacité en log(n) pour une concaténation successive, par exemple. Et en limitant le nombre d'opérations d'allocation, on limite aussi le bazar.

=> Ca ne deviendra pas lent en principe. Par contre, tu auras de l'espace perdu, oui (la raison principale étant que tous les pointeurs sont directs, donc il n'est pas possible de défragmenter la mémoire).

De toutes façons, c'est un problème rarement important, la plupart des applications utilisant très peu de mémoire de manière dynamique. Et les quelques applications qui le font implémentent généralement leur propre méthode de gestion de la mémoire pour les parties calculatoires. Les malloc et compagnie sont plus une "convenience" comme disent nos amis les anglais qu'un réel outil algorithmique, à mon sens.

Dans les ramasseurs de miettes de type Stop & Copy, pour les petits objets on utilise le double de l'espace requis et régulièrement on réorganise tous les blocs dans la zone duale (en modifiant les pointeurs dans la pile etc.) ce qui fait que l'allocation reste un "pointeur_de_tas += taille".

C'est quoi la zone duale ? google me sort des pages avec Britney Spears
De quels pointeurs tu parles ?

En gros, tu as deux zones, une pour l'allocation et une autre (ce que j'appelle la "zone duale"), de même taille, vide.
Le ramasse miettes recopie à la suite les blocs encore utilisés de la première zone dans la seconde.
Puisque les blocs ont changé d'adresse, il faut modifier les pointeurs vers la première zone pour qu'ils pointent vers les blocs déplacés dans la seconde.
Ça va ?

Et pour améliorer la cohérence du cache. Mais en pratique pas besoin de la diviser en 2.

Tu as besoin de 2x plus de ram seulement au moment du GC, et surtout il faut limiter ce système aux petits objets récents.

Boucles d'or : OK Mais ce n'est possible que dans des langages interprétés.

Ben non O_o, pourquoi penses-tu ça ?

Eh bien comment peux-tu intervenir sur les pointeurs du programme comme ça ?

avec les hooks de malloc dans la libc

Thibaut (./40) :
Eh bien comment peux-tu intervenir sur les pointeurs du programme comme ça ?

Il peut y avoir plein de méthodes. Ca sera intrusif, mais c'est faisable. Suffit que le programme ne manipule pas les pointeurs directement sans en référer au système d'allocation. Par exemple, en C++, tu peux créer une classe qui se comporte comme un pointeur mais fait un niveau d'indirection de plus. Ce n'est qu'un exemple d'implémentation pour un langage particulier, à toi de voir selon le contexte.

OK c'est bien ce que j'imaginais. C'est lent, ça ne correspond pas à ce dont j'ai besoin