I am not a C programmer but I will try!

Malloc/free - can turn into a tangled mess as you need to keep symmetry, and apps might have complex dep. graphs

Stack - wonderfully simple but often if you need to share things across the depths of your program you need to define variables in shallower parts - but you won’t know how much is needed ahead of time. Example a parsing library.

Arena - like a single malloc / free with it’s own stack. Use this to allocate memory for objects that can be all freed at the same time (if they need to be freed at all). No need to malloc for each object.

This came up before. TL;DR: If you use arena allocators everywhere then you won't have any memory errors!

I think the idea is a really interesting one but it would be better if he didn't wrap it in typical "I don't make mistakes" hubris. I mean I guess at least this time he has some more reason than "because I'm not stupid" but I think he's still wrong.

His technique probably reduces the chance of memory errors, but there's still nothing checking his work so he's still going to make mistakes.

The other issue he doesn't address is resource allocation. It's fine to just drop the memory of a lot of things but sometimes you have to close files, handles, etc. RAII handles that perfectly. I'm not sure about this.

I would say RAII and Rust's borrow checker are still superior but it's definitely true that they don't work well with arenas.

> I would say RAII and Rust's borrow checker are still superior but it's definitely true that they don't work well with arenas.

Note that this will definitely improve in future versions of Rust. Local allocators are an unstable feature already, and can support arena allocation.

As a C programmer who uses memory arenas quite frequently can you expand on what you know about Rust’s current or future support for such a feature?

I’d like to start writing new projects in Rust and I’d like to continue to use this approach to memory management!

You can of course use arenas in Rust just like in C. I think the parent was talking about support for using arenas as the memory for stuff like built-in containers (dynamic arrays, hash maps, etc.):

https://github.com/rust-lang/wg-allocators

Thank you! Yeah, something like bumpalo would work just fine right now but for the future this is a great interface:

https://docs.rs/bumpalo/latest/bumpalo/#nightly-rust-allocat...

  use bumpalo::Bump;
  
  let bump = Bump::new();
  
  let mut v = Vec::new_in(&bump);
  v.push(0);
  v.push(1);
  v.push(2);

> RAII handles that perfectly. I'm not sure about this.

If you're asking whether arena allocators can handle resource cleanup, then I think the answer is yes. One way to do it is to embed an intrusive linked list of destructors into your arena. So, to push an object onto the arena you would:

1. Push a function pointer (the object's destructor) and the current destructor list head onto the arena.

2. Update the destructor list head to point to the top of the arena.

3. Push the object's data onto the arena, as usual.

(source: https://www.ea.com/frostbite/news/scope-stack-allocation)

> The other issue he doesn't address is resource allocation. It's fine to just drop the memory of a lot of things

I think there is a fundamental difference between memory and most other resources: (process's) memory is a) effectively an internal detail while other resources are externally visible (open files/sockets/etc); b) as almost a consequence, it's pretty much anonymous: when you ask for 1 MiB of memory, you ask for free, unused memory; when you ask for file "/etc/passwd" or TCP port 8080, you ask for that exact file/port.

That's why you need special destructor calls for non-memory resources, to tell the external environment that this resource is now available for others to use. Memory, on the other hand... the OS with virtual memory support will generally be able to dispense free memory until the swap file consumes all of the available disk space, and even then, it could theoretically just start dropping pieces of swap (and when a process actually tries to access the gone memory, kill it with SIGSEGV) to prolong the agony. Throw in the most rudimentary form of in-process memory reclamation, and you won't notice memory leaks until well into months of constant uptime.

So do you argue that memory is different from point of view of resourse allocation/deallocation because it is much harder to exhaust memory than file descriptors, tcp ports and such like?

No, I am arguing that memory is (roughly speaking) an internal, private resource unlike most other things (files/sockets/pipes/processes/etc), and it's intended: other resources has state outside of the process which is used to communicate with other processes, or with specific hardware (e.g. GPU) or other machines. When you close() a file/socket, it's visible outside of the process, the other side receives inotify()/epoll() message, when a (child) process exits, its status and exit code change and SIGCHLD get sent, etc. Also, anonymity: if you need a socket connected to remote example.com:443, you want it to connected to example.com:443, not to something else; when you open a file/pipe, you want it to be able to communicate with someone else (in case of file, maybe with someone else from the past/future) — note how deeply this notion of sharing is built-in into file API by considering how difficult it was to design secure API for temp files which are files one doesn't want to share with anyone. But when you free() a block of memory... nothing outside of the process gets notified, really.

And that's why automated memory management (garbage collection) is a success story while attempts to blindly apply it to other resources failed: memory is different. Freeing other resources sends a very clear message to the external environment, including other processes, which is used for IPC while freeing memory doesn't.

Yes, in the end, memory in process is implemented by (shared) physical memory but modern OSes go to ridiculous length to support the illusion that it's unlimited and private. Yes, there is shared memory mappings which I explicitly leave outside the argument: those are externally visible, nameable, and hard to manage with GC.

As with everything, you need to use the tool for use-cases that it was designed for.

A downside of RAII is the hidden cost of unwinding, and predictability over CPU usage. If you have a resource that supports complicated internal transformations, and memory states, then you need an equally complicated destructor that can handle all those different states. If you're not careful with this you can get CPU spikes at scope-exits.

It's a good technical explanation of how arena allocation (a useful and easily googleable memory management technique) works in practice, in C, along with:

* A lot of arguing that all other ways of dealing with the problem (garbage collectors, RAII, etc) are misguided and make for worse programs. This is a lot more controversial than "arena allocation is useful" but I have some sympathy for it. He's not alone in thinking it. See the "Handmade Network" which this guy is associated with.

* A brief and unnecessary bit of free market fundamentalist politics, which seems par for the course for him.

* A general implication that he came up with this stuff himself, which he didn't. Arena allocation (under that name) dates back to the sixties.

He talks about gamedev, and arena allocators are common sense in gamedev. It's more like introduction of a gamedev concept to business programming.

If it seems like he is implying he came up with arena allocators himself, that is definitely not intended. I didn't read it like that though.

> A general implication that he came up with this stuff himself, which he didn't.

How in the world did you get this from the article? Of course I didn't invent it, nor did I ever claim (or imply) that.

I don't think you intended to create that impression, but I didn't go looking for it either. It's created by phrasing like

> In this post, I’ll be presenting an alternative to the traditional strategy of manual memory management that I’ve had success with: the arena allocator.

and

> My approach, on the other hand, is this: instead of assuming that malloc and free were the correct low-level operations, we can change the memory allocation interface...

Together with a complete absence of any reference to the history of the technique or any of the people besides you involved in its development.

It's not an accusation, but it's a clarification worth making as I genuinely think someone without knowledge of the subject could come away thinking you were presenting your own innovation.

Arena allocator lets you group allocations greatly reducing difficulty of correct manual memory management. As a bonus icache is used more economically too.