Quelle est la signification du terme arène par rapport à la mémoire?
Je lis un livre sur la mémoire comme concept de programmation. Dans l'un des derniers chapitres, l'auteur fait un usage intensif du mot arena, mais ne le définit jamais. J'ai cherché le sens de la Parole et sa relation avec 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'un arena spécifique."
"... ceci est utile lorsque l'on traite des fuites de mémoire ou lors de l'allocation à partir d'un arena spécifique."
"... si nous voulons désallouer la mémoire, nous allons désallouer l'ensemble 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 gestion de 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 de structures de données et d'objets 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 arena pour moi étant donné ces contextes?
Une arène est juste une grande pièce de mémoire contiguë que vous allouez une fois, puis utilisez 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; }
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 est uniquement utilisée 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 est d'avoir une arène par "tâche", et lorsque vous avez terminé la tâche, vous pouvez libérer l'arène entière en une seule fois et ne pas 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 de bibliothèque normale n'est pas assez bonne. 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 la mémoire vous-même.
j'irai avec celui-ci 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.
J'ajouterai 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 divisez, puis pouvez être libérée en une seule fois. L'avantage est que les petits appels répétés à malloc() peuvent être coûteux (chaque allocation de mémoire a un coût de performance: 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 attribuer cet espace d'adressage à la mémoire physique) où, comme si vous connaissiez un parc à billes, vous pouvez vous procurer une grande partie de la mémoire, puis la distribuer à vos variables selon la manière dont vous en avez besoin.
Considérez-le comme un synonyme de "tas". Normalement, votre processus n'a qu'un seul segment/arène, et toute l'allocation de mémoire se fait à partir de là.
Mais, parfois, vous avez une situation où vous souhaitez 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 à partir de quel tas allouer.
Par exemple, vous pourriez avoir un système de particules où de nombreux objets de la 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.
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 possède son propre mutex pour la protection des accès concurrents. Ainsi, s'il y a suffisamment d'arènes dans un tas de processus et un mécanisme pour répartir uniformément les accès de tas des threads entre eux, le potentiel de conflit 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 c'est le cas, l'arène est maintenant verrouillée et l'allocation 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 poursuivre sans blocage. Enfin, l'ID de la dernière arène utilisée par un thread est conservé dans le stockage local des threads, puis utilisé comme première arène pour essayer lorsque malloc () est ensuite appelé par ce thread. Par conséquent, tous les appels à malloc () se poursuivront sans blocage.
Vous pouvez également vous référer à ce lien:
http://www.codeproject.com/Articles/44850/Arena-Allocator-DTOR-and-Embedded-Preallocated-Buf