Qual è il significato del termine arena in relazione alla memoria?

Sto leggendo un libro sulla memoria come concetto di programmazione. In uno dei capitoli successivi, l'autore fa un uso massiccio della parola arena , ma non la definisce mai. Ho cercato il significato della parola e come si riferisce alla memoria, ma non ho trovato nulla. Ecco alcuni contesti in cui l'autore usa il termine:

"Il prossimo esempio di serializzazione incorpora una strategia chiamata allocazione della memoria da un'arena specifica ".

"... questo è utile quando si ha a che fare con perdite di memoria o durante l'allocazione da un'arena specifica ."

"... se vogliamo deallocare la memoria, deallocheremo l'intera arena ."

L'autore usa il termine più di 100 volte in un capitolo. L'unica definizione nel glossario è:

allocazione dall'arena - Tecnica di allocare prima un'arena e poi di gestire l'allocazione / deallocazione all'interno dell'arena dal programma stesso (piuttosto che dal gestore della memoria del processo); utilizzato per la compattazione e la serializzazione di strutture e oggetti di dati complessi o per la gestione della memoria in sistemi critici per la sicurezza e / o con tolleranza ai guasti.

Qualcuno può definire arena per me dati questi contesti?

Un'arena è solo un grande pezzo di memoria contiguo che si alloca una volta e quindi si utilizza per gestire la memoria manualmente distribuendo parti di quella memoria. Per esempio:

char * arena = malloc(HUGE_NUMBER);

unsigned int current = 0;

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

Il punto è che hai il pieno controllo su come funziona l'allocazione della memoria. L'unica cosa al di fuori del tuo controllo è la singola chiamata di libreria per l'allocazione iniziale.

Un caso d'uso popolare è quello in cui ogni arena viene utilizzata solo per allocare blocchi di memoria di una singola dimensione fissa. In tal caso, puoi scrivere algoritmi di recupero molto efficienti. Un altro caso d'uso è avere un'arena per "attività" e, quando hai finito con l'attività, puoi liberare l'intera arena in una volta sola e non devi preoccuparti di tenere traccia delle singole deallocazioni.

Ognuna di queste tecniche è molto specializzata e generalmente torna utile solo se sai esattamente cosa stai facendo e perché la normale allocazione della libreria non è abbastanza buona. Nota che un buon allocatore di memoria farà già molte magie da solo, e hai bisogno di una discreta quantità di prove che non è abbastanza buono prima di iniziare a gestire la memoria da solo.

Vado con questo come una possibile risposta.

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

Aggiungerò i sinonimi di Wikipedia : regione, zona, arena, area o contesto della memoria.

Fondamentalmente è la memoria che ottieni dal sistema operativo e dividi, quindi può essere liberata tutta in una volta. Il vantaggio di ciò è che ripetute piccole chiamate a malloc()potrebbero essere costose (ogni allocazione di memoria ha un costo in termini di prestazioni: il tempo necessario per allocare la memoria nello spazio degli indirizzi logici del programma e il tempo necessario per assegnare quello spazio degli indirizzi alla memoria fisica) dove come se conoscessi un parco giochi puoi procurarti un bel pezzo di memoria e poi distribuirlo alle tue variabili come / come ne hai bisogno.

Consideralo un sinonimo di "mucchio". Normalmente, il tuo processo ha solo un heap / arena e tutta l'allocazione della memoria avviene da lì.

Tuttavia, a volte si ha una situazione in cui si raggruppa una serie di allocazioni (ad esempio per le prestazioni, per evitare la frammentazione, ecc.). In tal caso, è meglio allocare un nuovo heap / arena, quindi per qualsiasi allocazione è possibile decidere da quale heap allocare.

Ad esempio, potresti avere un sistema di particelle in cui molti oggetti della stessa dimensione vengono frequentemente allocati e deallocati. Per evitare di frammentare la memoria, è possibile allocare ciascuna particella da un heap che viene utilizzato solo per quelle particelle e tutte le altre allocazioni verrebbero dall'heap predefinito.

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

La libreria condivisa libc.so.x contiene il componente glibc e il codice dell'heap risiede al suo interno. L'attuale implementazione dell'heap utilizza più sotto-heap indipendenti chiamati arene. Ogni arena ha il proprio mutex per la protezione della concorrenza. Pertanto, se ci sono arene sufficienti all'interno dell'heap di un processo e un meccanismo per distribuire gli accessi all'heap dei thread in modo uniforme tra di loro, il potenziale di contesa per i mutex dovrebbe essere minimo. Risulta che questo funziona bene per le allocazioni. In malloc (), viene eseguito un test per vedere se il mutex per l'arena di destinazione corrente per il thread corrente è libero (trylock). Se è così, l'arena è ora bloccata e l'assegnazione procede. Se il mutex è occupato, ogni arena rimanente viene provata a turno e utilizzata se il mutex non è occupato. Nel caso in cui nessuna arena possa essere bloccata senza bloccare, viene creata una nuova arena fresca. Questa arena per definizione non è già bloccata, quindi l'allocazione può ora procedere senza bloccare. Infine, l'ID dell'arena usata per ultima da un thread viene conservata nella memoria locale del thread e successivamente utilizzata come prima arena da provare quando malloc () viene chiamata successivamente da quel thread. Pertanto tutte le chiamate a malloc () procederanno senza essere bloccate.

Puoi anche fare riferimento a questo link:

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