Untangling Lifetimes: The Arena Allocator

Post by gjulianm » Mon, Oct 31, 2022, 2:51 PM UTC

williamcotton wrote: post #42

gjulianm wrote: post #28

> In other words, you may treat the operating system as “the ultimate garbage collector”—freeing memory when it is unnecessary will simply waste both your and the user’s time, and lead to code complexity and bugs that would otherwise not exist. Unfortunately, many popular programming education resources teach that cleanup code is always necessary. This is false. I disagree. One, I think the set of C code where both "…

I use arenas for HTTP request handlers. The JSON built or parsed is only going to be around for the lifetime of the request. It's much simpler and faster to use an arena than to do reference counting wrapped around malloc/free. Here's an example where in a commit I swapped in an arena: https://github.com/williamcotton/express-c/commit/4ae53f38e3...

Post by flohofwoe » Mon, Oct 31, 2022, 2:57 PM UTC

TomSwirly wrote: post #48

flohofwoe wrote: post #23

Earlier quoted context omitted.

IMHO the problem with C++ style RIIA is that it's not just about calling cleanup code at the end of a scope (this would be fine, really), but the 'rat's tail' that's attached to RAII for dynamic memory management: you also need the compiler to be able to invoke user-provided code for 'copy' and 'move' operations (or better named: deep- and flat-copy), you need different reference types to define ownership details (e.…

> (or better named: deep- and flat-copy) That's worse naming, not better! In particular, a copy does not change the thing it copies - but a C++ move does change the thing it moves from.

Post by gjulianm » Mon, Oct 31, 2022, 3:10 PM UTC

omginternets wrote: post #37

DougBTX wrote: post #7

The author should take another look at RIIA. The first big difference is that it works with non-memory resources too, for example open/close for files. The second is that it makes heap allocated data feel a lot like stack allocated data, since the resources are ultimately owned by variables on the stack. With “move semantics” resources can be passed as arguments and returned by functions too, so the example of lifeti…

Could someone please explain the usefulness of RAII? As I understand it, RAII refers to the initialization semantics of certain languages, most famously C++. If I remember correctly, it effectively states that variable declarations amount to reserving memory resources and nothing else; memory is not zeroed, for instance. My question is: what makes this so useful? Looking at wikipedia, the focus seems to be on lifetim…

    class Config {
        Config() { this->file = nullptr; }
        void load(const std::string& path) { this->file = open(path); }
        void close() { this->file->close(); }

    class Config { 
        Config(const std::string& path) { this->file = open(path); }
        ~Config() { this->file->close(); }

Post by maccard » Mon, Oct 31, 2022, 3:22 PM UTC

flohofwoe wrote: post #53

TomSwirly wrote: post #48

Earlier quoted context omitted.

> (or better named: deep- and flat-copy) That's worse naming, not better! In particular, a copy does not change the thing it copies - but a C++ move does change the thing it moves from.

Ok "flat-copy-with-src-invalidation". Somehow "move" makes it sound more efficient than copying a C struct, but it's actually the same thing (for POD structs), for non-POD it's even slightly more expensive because you need to fix up the source.

Post by williamcotton » Mon, Oct 31, 2022, 3:27 PM UTC

andreareina wrote: post #45

vitiral wrote: post #36

Earlier quoted context omitted.

Of course, it's still manual memory and pointer management after all. You could manually assign a pointer to 0xDEADBEEF if you want, or you could tell the arena to pop data that you are still using. The point is not perfection, it is simplicity and mapping tools to requirements.

Maybe I'm not understanding the point of the article then. It starts out as a polemical rant against the suggestion to use safer languages, and I guess I expected it to culminate in something more profound wrt safety. I use managed memory languages so I'm sure there's stuff I'm missing.