Untangling Lifetimes: The Arena Allocator

on the contrary, I find this article to be excellent. none of this stuff was ever taught to me in school, which is nuts given that the school I went to was specifically tailored toward video game development, and had[0] students create their own game engines almost entirely from scratch in C (a helper library was provided to do basic graphics things) during their second semester, and then had students create their own game engines, entirely from scratch, in C++ during their sophomore year.

again: nothing like this was ever presented to us, except as some sage wisdom from upperclassmen who had figured it out on their own. you learn malloc/free when you learn C, then you learn new/delete/RAII when you learn C++, and you get a brief overview of how garbage collection broadly works in higher-level languages, and that's it, that's the education about memory management. I had never explicitly heard of the concept of a "lifetime" until Rust started gaining traction. it wasn't until working on my sophomore year game engine that an upperclassman explained the idea of building a memory-managing array-like data structure that, instead of reallocating when the capacity is reached, instead leaves the existing items where they were and allocates a new "page" of memory, so as to ensure pointers to existing items remain functional.

hell, I'd never even been exposed to the idea of a per-frame "scratch" pool allocator until I saw Jon Blow talk about having such a thing as a built-in feature of his new programming language. once I saw how it worked, I was floored—it's such an easy-to-explain concept, infinitely useful, basically gives you "garbage collection for free" for any number of one-off things you need allocations for in a given frame of a video game (or other interactive application)—without the need for Actual Garbage Collection!

I agree that this article is a bit lengthy, but in my opinion it does a great job of setting up the knowledge necessary to understand what it's talking about, so I'm not really sure how I'd do a better job. what in particular did you find condescending about it, especially within the first fifth of the article?

---

[0] from what I've heard, this from-scratch game-engine-creation is now gone from the curriculum entirely, and now students just make shit in unreal or unity, which is tragic, imo.

it's hard to present contrarian ideas without coming across as overly defensive, sneering, etc., especially when the ideas are conveyed through text, and especially when you, the reader, disagree with them. the paragraph you posted is true to my experience, and true to the experience of everyone I know who's gone through CS school.

> Education around memory management—as it was presented to me—was purely a historical, academic endeavor. How did the Linux kernel originally do memory management? Let’s do an assignment on that subject so you can see how gross it is! Eww, look at that malloc! Weird! Oh, don’t forget to free it! But don’t worry, kiddo; in next class, you can return to your “safe” and “managed” padded-room languages where bugs and instabilities are “impossible” (or so they claim).

was your CS education appreciably different to what the author wrote above? is this not the increasingly-prevailing attitude among contemporary programmers?

> As for your post, it's hard for me to get worked up about whatever the game programming curriculum is these days. There are more important things in the world. Good to keep things in perspective: it's school... for game programming.

ok, should I refrain from posting unless I have something to say about world hunger or climate change or something?? hopefully you saw the point I was making which is that memory management techniques like those described in the article are pretty crucial for making high-performance real-time interactive applications, and hopefully you understand that not being taught about such things at a school whose whole point is to teach such things is pretty crazy—especially since, from the looks of things, these things aren't really being taught in school anywhere else, either!

do you disagree with the author about the importance of manual memory management techniques and theory? if not, then what other point were you trying to make with that last paragraph? your reply is very confusing to me.

---

EDIT:

> If you slow down

> Maybe because it's a relatively inconsequential topic (in the grand scheme of things) we can approach it more calmly and soberly instead of with a hyperventilating tone.

> I would also say that while it can be difficult for some people to approach tendentious issues without being combative, it is indeed possible. Some might even say it's a useful skill to spend some time picking up.

these are more condescending than anything in the article—projecting irrationality onto others is unbecoming.

> That said, whether or not I agree with the author isn't salient

it should be! discussions about programming techniques and methodologies are far more interesting and relevant than sentence after sentence explaining why you think the tone of the introduction of a lengthy article is Bad And Wrong, and, despite refusing to read the rest of said article, claiming that said article's length is also problematic.

I generally agree with what you wrote but have some corections based on having worked with arena allocators.

4. Nothing prevents arena allocators to track other resources than memory.

7. This is not a big problem in practice from my experience. You can just do like Zig and always pass an allocator or you can use global/thread local variables like PostgreSQL.

But I also would like to add my biggest issue with arena allocators: they do nothing against use after free.

My take is that arenas are very useful, but not to use as a stack so much as to allocate a bunch of memory piecemeal but free it all at once. (The "pop" function in TFA is just not relevant to my use cases for arenas.)

For example, if you're decoding a certificate, or maybe something larger and more complex, a decoder might malloc() every little thing as it goes, which then necessitates free()ing each of those things when you are done with the whole decoded thing. But if you can have the decoder allocate from an arena, then when you're done using the decoded object you can just free the arena.

The decoding example is very common. Whether it's JSON, XML, ASN.1/DER/whatever, Protocol Buffers, Flat Buffers, or anything else, it is very common for decoders to create a ton of garbage to collect. Optimizing that garbage collection seems like a useful thing to do, but it's hard to do in a memory-safe language because every reference to a sub-object of the decoded object will need to be dropped in order for the object's arena to be released. How would one handle this in Rust, C++, or Java?

If you use a try-with-resources in Java, then the closeables are closed immediately when the try block exits, and in reverse order to acquisition.