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

100

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?

Nocturno
fonte
Qual é o nome do livro?
yaobin
1
Memória @yaobin como um conceito de programação em C e C ++ por Frantisek Franek.
Nocturno

Respostas:

111

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.

Kerrek SB
fonte
25
É uma boa resposta, mas considere excluir ou alterar o último parágrafo. Você realmente não precisa de nenhuma evidência. Sempre que você sabe como usar a memória, sabe mais do que um "bom" alocador de uso geral e, se usar esse conhecimento, seu alocador personalizado sempre vencerá. Alocadores não são mágicos. Uma arena é útil se você tiver muitos itens que morrem todos ao mesmo tempo, um ponto bem definido no tempo. Isso é tudo que você precisa saber. Não é ciência de foguetes.
Andreas Haferburg,
11
@AndreasHaferburg: O alocador de memória da biblioteca padrão tem automaticamente uma enorme vantagem sobre a escrita personalizada, ou seja, você não precisa escrever / testar / depurar / manter etc. Mesmo se você tiver certeza, sem nenhuma evidência de que pode melhorar o desempenho gerenciando sua própria alocação, você ainda precisa de boas evidências antes de decidir que essa melhoria vale a pena.
ruakh
17
@ruakh Eu simplesmente não gosto dessa mentalidade de culto à carga que é repetida um milhão de vezes em todos os lugares como "sabedoria". "Os deuses do C ++ nos deram isso, então temos que usá-lo." E meu favorito: "É mágico". Não. Não é mágica. É apenas um algoritmo tão simples que até um computador pode executá-lo. No meu livro, isso está muito longe de ser mágico. Meu palpite: você subestima o impacto que a alocação de memória pode ter no desempenho e superestima o quão complicadas são as arenas. Se o desempenho é mais importante do que o tempo do desenvolvedor, é uma decisão de negócios um tanto inútil para discutir em SO.
Andreas Haferburg,
8
@AndreasHaferburg: Claro, tcmalloc usa algum algoritmo específico, e a ideia por trás dele é fácil de explicar, mas a implementação ainda é complexa e não trivial. Mais importante ainda, é necessário conhecimento específico da plataforma para obter a ordem correta da memória. Eu uso "mágica" para coisas que não podem ser escritas portavelmente pelo usuário (como um mutex eficiente, ou tcmalloc, ou o nome do tipo de um lambda), ou apenas com heroísmo extremo (como std :: function); Não quero dizer isso como "não pode ser compreendido".
Kerrek SB
12
@AndreasHaferburg: E meu conselho final não é tanto dizer que é, em princípio, difícil "saber melhor do que o padrão", mas sim que o custo de manutenção de uma solução personalizada é alto (alguém tem que escrever, documentar, pegar certo, e outra pessoa tem que consertar os bugs, e todo mundo tem que revisar e reverificar as suposições originais conforme o uso se espalha), e que você precisa de evidências para justificar esse custo.
Kerrek SB
10

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.

Mike
fonte
5

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.

Adam Rosenfield
fonte
5

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

Rahul Tripathi
fonte
3
Para sua informação, ao postar links, você deve postar um resumo para que, se o artigo vinculado for embora, sua postagem ainda seja útil.
stonemetal
5
Este parece ser um copiar e colar de bozemanpass.com/info/linux/malloc/Linux_Heap_Contention.html Por favor, crédito às suas fontes quando usá-las literalmente.
jscs