What is the meaning of the term arena in relation to memory?

I'll go with this one as a possible answer.

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

I'll add Wikipedia's synonyms: region, zone, arena, area, or memory context.

Basically it's memory you get from the OS, and divvy out, then can be freed all at once. The advantage to this is that repeated small calls to malloc() could be costly (Every memory allocation has a performance cost: the time it takes to allocate the memory in your program’s logical address space and the time it takes to assign that address space to physical memory) where as if you know a ball park you can get yourself a big chunk of memory then hand it out to your variables as/how you need it.

An arena is just a large, contiguous piece of memory that you allocate once and then use to manage memory manually by handing out parts of that memory. For example:

char * arena = malloc(HUGE_NUMBER);

unsigned int current = 0;

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

The point is that you get full control over how the memory allocation works. The only thing outside your control is the single library call for the initial allocation.

One popular use case is where each arena is only used to allocate memory blocks of one single, fixed size. In that case, you can write very efficient reclamation algorithms. Another use case is to have one arena per "task", and when you're done with the task, you can free the entire arena in one go and don't need to worry about tracking individual deallocations.

Each of those techniques is very specialized and generally only comes in handy if you know exactly what you're doing and why the normal library allocation is not good enough. Note that a good memory allocator will already do lots of magic itself, and you need a decent amount of evidence that that's not good enough before you start handling memory yourself.

Think of it as a synonym for 'heap'. Ordinarily, your process only has one heap/arena, and all memory allocation happens from there.

But, sometimes you have a situation where you would to group a series of allocations together (e.g. for performance, to avoid fragmentation, etc.). In that case, it's better to allocate a new heap/arena, and then for any allocation, you can decide which heap to allocate from.

For example, you might have a particle system where lots of objects of the same size are being frequently allocated and deallocated. To avoid fragmenting memory, you could allocate each particle from a heap which is only used for those particles, and all other allocations would come from the default heap.