Quelle est la signification du terme arène par rapport à la mémoire?

Je lis un livre sur la mémoire en tant que concept de programmation. Dans l'un des derniers chapitres, l'auteur fait un usage intensif du mot arène , mais ne le définit jamais. J'ai cherché le sens du mot et comment il se rapporte à la mémoire, et je n'ai rien trouvé. Voici quelques contextes dans lesquels l'auteur utilise le terme:

"Le prochain exemple de sérialisation incorpore une stratégie appelée allocation de mémoire à partir d'une arène spécifique ."

"... ceci est utile pour traiter les fuites de mémoire ou lors de l'allocation à partir d'une arène spécifique ."

"... si nous voulons désallouer la mémoire alors nous désallouerons toute l' arène ."

L'auteur utilise le terme plus de 100 fois dans un chapitre. La seule définition du glossaire est:

allocation depuis l'arène - Technique d'allocation d'une arène d'abord, puis de gérer l'allocation / désallocation au sein de l'arène par le programme lui-même (plutôt que par le gestionnaire de mémoire de processus); utilisé pour le compactage et la sérialisation d'objets et de structures de données complexes, ou pour la gestion de la mémoire dans des systèmes critiques pour la sécurité et / ou tolérants aux pannes.

Quelqu'un peut-il définir l' arène pour moi compte tenu de ces contextes?

Une arène est juste un gros morceau de mémoire contigu que vous allouez une fois et que vous utilisez ensuite pour gérer manuellement la mémoire en distribuant des parties de cette mémoire. Par exemple:

char * arena = malloc(HUGE_NUMBER);

unsigned int current = 0;

void * my_malloc(size_t n) { current += n; return arena + current - n; }

Le fait est que vous obtenez un contrôle total sur le fonctionnement de l'allocation de mémoire. La seule chose hors de votre contrôle est l'appel de bibliothèque unique pour l'allocation initiale.

Un cas d'utilisation courant est celui où chaque arène n'est utilisée que pour allouer des blocs de mémoire d'une seule taille fixe. Dans ce cas, vous pouvez écrire des algorithmes de récupération très efficaces. Un autre cas d'utilisation consiste à avoir une arène par «tâche», et lorsque vous avez terminé la tâche, vous pouvez libérer toute l'arène en une seule fois sans avoir à vous soucier du suivi des désallocations individuelles.

Chacune de ces techniques est très spécialisée et n'est généralement utile que si vous savez exactement ce que vous faites et pourquoi l'allocation normale de la bibliothèque n'est pas suffisante. Notez qu'un bon allocateur de mémoire fera déjà beaucoup de magie lui-même, et vous avez besoin d'une quantité décente de preuves que ce n'est pas assez bon avant de commencer à gérer vous-même la mémoire.

J'irai avec celui-ci comme réponse possible.

•Memory Arena (also known as break space)--the area where dynamic runtime memory is stored. The memory arena consists of the heap and unused memory. The heap is where all user-allocated memory is located. The heap grows up from a lower memory address to a higher memory address.

J'ajouterai les synonymes de Wikipedia : région, zone, arène, zone ou contexte de mémoire.

Fondamentalement, c'est la mémoire que vous obtenez du système d'exploitation et que vous divisez, puis peut être libérée en même temps. L'avantage est que de petits appels répétés à malloc()peuvent être coûteux (chaque allocation de mémoire a un coût en termes de performances: le temps qu'il faut pour allouer la mémoire dans l'espace d'adressage logique de votre programme et le temps qu'il faut pour affecter cet espace d'adressage à la mémoire physique) où, comme si vous connaissiez un parc de balles, vous pouvez vous procurer une grande partie de la mémoire, puis la distribuer à vos variables selon vos besoins.

Considérez-le comme un synonyme de «tas». Normalement, votre processus n'a qu'un seul tas / arène, et toutes les allocations de mémoire se produisent à partir de là.

Mais, parfois, vous avez une situation où vous devez regrouper une série d'allocations (par exemple pour les performances, pour éviter la fragmentation, etc.). Dans ce cas, il est préférable d'allouer un nouveau tas / arène, puis pour toute allocation, vous pouvez décider de quel tas allouer.

Par exemple, vous pouvez avoir un système de particules dans lequel de nombreux objets de même taille sont fréquemment alloués et désalloués. Pour éviter de fragmenter la mémoire, vous pouvez allouer chaque particule à partir d'un tas qui n'est utilisé que pour ces particules, et toutes les autres allocations proviendraient du tas par défaut.

À partir de http://www.bozemanpass.com/info/linux/malloc/Linux_Heap_Contention.html :

La bibliothèque partagée libc.so.x contient le composant glibc et le code du tas y réside. L'implémentation actuelle du tas utilise plusieurs sous-tas indépendants appelés arènes. Chaque arène a son propre mutex pour la protection de la concurrence. Ainsi, s'il y a suffisamment d'arènes dans le tas d'un processus, et un mécanisme pour répartir les accès au tas des threads uniformément entre eux, alors le potentiel de contention pour les mutex devrait être minime. Il s'avère que cela fonctionne bien pour les allocations. Dans malloc (), un test est effectué pour voir si le mutex de l'arène cible actuelle pour le thread actuel est libre (trylock). Si tel est le cas, l'arène est maintenant verrouillée et l'attribution se poursuit. Si le mutex est occupé, chaque arène restante est essayée à son tour et utilisée si le mutex n'est pas occupé. Dans le cas où aucune arène ne peut être verrouillée sans blocage, une nouvelle arène est créée. Cette arène par définition n'est pas déjà verrouillée, donc l'allocation peut maintenant se dérouler sans blocage. Enfin, l'ID de la dernière arène utilisée par un thread est conservé dans le stockage local du thread, puis utilisé comme première arène à essayer lorsque malloc () est ensuite appelé par ce thread. Par conséquent, tous les appels à malloc () se dérouleront sans blocage.

Vous pouvez également vous référer à ce lien:

http://www.codeproject.com/Articles/44850/Arena-Allocator-DTOR-and-Embedded-Preallocated-Buf