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

Question

Je suis en train de lire 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 "mémoire". arène mais ne le définit jamais. J'ai cherché la signification du mot et son rapport avec la mémoire, et je n'ai rien trouvé. Voici quelques contextes dans lesquels l'auteur utilise le terme :

"L'exemple suivant de sérialisation incorpore une stratégie appelée allocation de mémoire à partir d'un arène ."

"...ceci est utile lors de fuites de mémoire ou lors d'une allocation à partir d'un arène ."

"...si nous voulons désallouer la mémoire, alors nous allons désallouer la tout le site arène ."

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

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

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

Answer 1

Une arène est simplement un grand morceau contigu de mémoire que vous allouez une fois et que vous utilisez ensuite pour gérer la mémoire manuellement 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; }

L'intérêt est que vous avez un contrôle total sur le fonctionnement de l'allocation de la mémoire. La seule chose qui échappe à votre contrôle est l'appel unique à la bibliothèque pour l'allocation initiale.

Un cas d'utilisation populaire est celui où chaque arène est uniquement utilisée pour allouer des blocs de mémoire d'une taille unique et fixe. Dans ce cas, vous pouvez écrire des algorithmes de récupération très efficaces. Un autre cas d'utilisation est d'avoir une arène par "tâche", et quand vous avez fini avec la tâche, vous pouvez libérer l'arène entière en une seule fois et n'avez pas besoin de vous soucier du suivi des désallocations individuelles.

Chacune de ces techniques est très spécialisée et ne s'avère généralement utile que si vous savez exactement ce que vous faites et pourquoi l'allocation normale de la bibliothèque ne suffit pas. 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 bien avant de commencer à manipuler la mémoire vous-même.

Answer 2

Je vais aller avec celui-là comme une 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.

Je vais ajouter Les synonymes de Wikipédia : région, zone, arène, aire, ou contexte de mémoire.

En gros, c'est de la mémoire que vous obtenez du système d'exploitation, que vous divisez et qui peut être libérée en une seule fois. L'avantage de cette méthode est que des petits appels répétés à malloc() pourrait s'avérer coûteux (toute 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 assigner cet espace d'adressage à la mémoire physique), alors que si vous connaissez un parc à balles, vous pouvez vous procurer un gros morceau de mémoire puis le distribuer à vos variables selon vos besoins.

Answer 3

Considérez-le comme un synonyme de "tas". Normalement, votre processus ne possède qu'un seul tas/arène, et toute l'allocation de mémoire se fait à partir de celui-ci.

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

Par exemple, vous pouvez avoir un système de particules où de nombreux objets de même taille sont fréquemment alloués et désalloués. Pour éviter de fragmenter la mémoire, vous pourriez 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.

Answer 4

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. réside à l'intérieur de celle-ci. L'implémentation actuelle du tas utilise plusieurs sous-répertoires indépendants appelés arènes. Chaque arène possède son propre mutex pour la protection contre la concurrence. Ainsi, s'il y a suffisamment d'arènes dans le tas d'un processus, et un mécanisme pour distribuer les accès au tas des fils des threads entre elles, alors le potentiel de contention pour les mutex devrait être minimal. pour les mutex devrait être minimal. Il s'avère que cela fonctionne bien pour les allocations. Dans malloc(), un test est effectué pour voir si le mutex pour l'arène cible actuelle pour le thread actuel est libre (trylock). Si c'est le cas alors l'arène est maintenant verrouillée et l'allocation se poursuit. Si le mutex est occupé, alors chaque arène restante est testée à son tour et utilisée si le mutex est libre. mutex n'est pas occupé. Dans le cas où aucune arène ne peut être verrouillée sans bloquer, une nouvelle arène est créée. Cette arène par définition n'est n'est pas déjà verrouillée, donc l'allocation peut maintenant se faire sans blocage. bloquer. Enfin, l'identifiant de la dernière arène utilisée par un thread est conservée dans le stockage local du thread, et utilisée par la suite comme la première arène à essayer lors du prochain appel de malloc() 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