Qual é o significado do termo arena em relação à memória?

Estou lendo um livro sobre a memória como conceito de programação. Em um dos capítulos posteriores, o autor faz uso intenso da palavra arena , mas nunca a define. Procurei o significado da palavra e como ela se relaciona com a memória e não encontrei nada. Aqui estão alguns contextos em que o autor usa o termo:

"O próximo exemplo de serialização incorpora uma estratégia chamada alocação de memória de uma arena específica ."

"... isso é útil ao lidar com vazamentos de memória ou ao alocar de uma arena específica ."

"... se quisermos desalocar a memória, então desalocaremos toda a arena ."

O autor usa o termo mais de 100 vezes em um capítulo. A única definição no glossário é:

alocação da arena - Técnica de alocar uma arena primeiro e então gerenciar a alocação / desalocação dentro da arena pelo próprio programa (e não pelo gerenciador de memória do processo); usado para compactação e serialização de estruturas e objetos de dados complexos ou para gerenciamento de memória em sistemas críticos de segurança e / ou tolerantes a falhas.

Alguém pode definir a arena para mim, dados esses contextos?

Uma arena é apenas um pedaço grande e contíguo de memória que você aloca uma vez e depois usa para gerenciar a memória manualmente, distribuindo partes dessa memória. Por exemplo:

char * arena = malloc(HUGE_NUMBER);

unsigned int current = 0;

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

A questão é que você obtém controle total sobre como funciona a alocação de memória. A única coisa fora do seu controle é a única chamada de biblioteca para a alocação inicial.

Um caso de uso popular é onde cada arena é usada apenas para alocar blocos de memória de um único tamanho fixo. Nesse caso, você pode escrever algoritmos de recuperação muito eficientes. Outro caso de uso é ter uma arena por "tarefa" e, quando você terminar a tarefa, poderá liberar a arena inteira de uma vez e não precisa se preocupar em rastrear desalocações individuais.

Cada uma dessas técnicas é muito especializada e geralmente só é útil se você souber exatamente o que está fazendo e por que a alocação normal da biblioteca não é boa o suficiente. Observe que um bom alocador de memória já faz muita mágica e você precisa de uma quantidade razoável de evidências de que isso não é bom o suficiente antes de começar a lidar com a memória por conta própria.

Vou com esta como uma resposta possível.

•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.

Adicionarei sinônimos da Wikipedia : região, zona, arena, área ou contexto de memória.

Basicamente, é a memória que você obtém do sistema operacional, distribui e pode ser liberada de uma vez. A vantagem disso é que pequenas chamadas repetidas para malloc()podem ser caras (cada alocação de memória tem um custo de desempenho: o tempo que leva para alocar a memória no espaço de endereço lógico do seu programa e o tempo que leva para atribuir esse espaço de endereço à memória física) onde, como se você conhecesse um estádio, você pode conseguir um grande pedaço de memória e distribuí-lo para suas variáveis ​​como / como você precisar.

Pense nisso como um sinônimo para 'heap'. Normalmente, seu processo tem apenas um heap / arena e toda a alocação de memória acontece a partir daí.

Mas, às vezes, você tem uma situação em que agruparia uma série de alocações (por exemplo, para desempenho, para evitar fragmentação, etc.). Nesse caso, é melhor alocar um novo heap / arena e, para qualquer alocação, você pode decidir de qual heap alocar.

Por exemplo, você pode ter um sistema de partículas em que muitos objetos do mesmo tamanho são freqüentemente alocados e desalocados. Para evitar a fragmentação da memória, você pode alocar cada partícula de um heap que é usado apenas para essas partículas, e todas as outras alocações virão do heap padrão.

De http://www.bozemanpass.com/info/linux/malloc/Linux_Heap_Contention.html :

A biblioteca compartilhada libc.so.x contém o componente glibc e o código de heap reside dentro dele. A implementação atual do heap usa vários sub-heaps independentes chamados arenas. Cada arena tem seu próprio mutex para proteção de concorrência. Portanto, se houver arenas suficientes dentro de um heap de processo e um mecanismo para distribuir os acessos de heap de threads igualmente entre eles, o potencial de contenção para mutexes deve ser mínimo. Acontece que isso funciona bem para alocações. Em malloc (), um teste é feito para ver se o mutex para a arena de destino atual para o segmento atual está livre (trylock). Nesse caso, a arena agora está bloqueada e a alocação continua. Se o mutex estiver ocupado, cada arena restante será tentada por vez e usada se o mutex não estiver ocupado. No caso de nenhuma arena poder ser bloqueada sem bloqueio, uma nova arena é criada. Esta arena, por definição, ainda não está bloqueada, portanto, a alocação agora pode prosseguir sem bloqueio. Por último, a ID da arena usada pela última vez por um encadeamento é retida no armazenamento local do encadeamento e, subsequentemente, usada como a primeira arena a ser tentada quando malloc () é chamado pela próxima vez por esse encadeamento. Portanto, todas as chamadas para malloc () continuarão sem bloqueio.

Você também pode consultar este link:

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