[monocasa]

So I kind of disagree with the idea that arenas are all about deallocation at once. There's other contexts where you have separate arenas but don't plan on deallocating in blocks, mainly around when you have memory with different underlying semantics. "This block of memory is faster, but not coherent and needs to be manually flushed for DMA", "this block of memory is fastest but just not DMA capable at all", "there's only 2k of this memory, but it's basically cache", "this memory is large, fairly slow, but can do whatever", "this block of memory is non volatile, but memory mapped", etc.

I'd say that arenas are kind of a superset of both what you and I are talking about.

[hinkley]

I can’t remember the last time I read C code, but I do recall a particular time when I was reading a library that had been written with a great deal of attention to reliability. The first thing it did was allocate enough memory for the shutdown operations. That way on a malloc() failure, it could still do a a completely orderly shutdown. Or never start in the first place.

From that standpoint, you could also categorize arenas on a priority basis. This one is for recovery operations, this one for normal operation, and whatever is left for low priority tasks.

[bch]

> The first thing it did was allocate enough memory for the shutdown operations.

That is clever and beautiful. Have to look for chances to do similar to see if I can establish a new habit myself.

[Someone]

That strategy is more important on systems that don’t do demand paged virtual memory. In Think Class Library on classic Mac OS, it was called the “Rainy day fund”.

One can also do that in stages:

- allocate a large block at startup

- when running out of memory, reallocate it at a smaller size and warn the user

- when running out of memory again, free the block and attempt an orderly shutdown.

[MaxBarraclough]

Those aren't arenas. I'm inclined to agree with Wikipedia's definition, which does emphasise deallocation all at once:

> A region, also called a zone, arena, area, or memory context, is a collection of allocated objects that can be efficiently deallocated all at once.

[monocasa]

I mean, wiki uses zone and region here as synonyms, so according to wiki that definition applies just as much. And yet:

https://www.kernel.org/doc/gorman/html/understand/understand...

Like, as a embedded developer, these concepts are used pretty much every day. And in a good chunk of those, deallocation isn't allowed at all, so you can't say that the definition is around deallocation at once.

You can also see how glibc's malloc internally creates arenas, but that's not to deallocate at once, but instead to manage different locking semantics. https://sourceware.org/glibc/wiki/MallocInternals

[Someone]

can be efficiently deallocated all at once.

There are implementations of arenas that, basically, act as separate memory managers. You can allocate and free memory inside them at will, but can also deallocate the whole thing in one sweep. The latter can be a lot faster, but of course, it requires you to know you can throw away all that memory in one go (handling web requests is the exemplar use case)