Untangling Lifetimes: The Arena Allocator • Hacker News Board

Re: Untangling Lifetimes: The Arena Allocator

#91

Post by vitiral » Tue, Nov 01, 2022, 1:56 AM UTC

kevin_thibedeau wrote: post #75

vitiral wrote: post #34

Earlier quoted context omitted.

There is a separate solution for files: defer. Defer can be implemented trivially in assembly by putting the deferred block on the return stack (then the defer block simply returns). This glosses over handling the local stack, but it's not impossible. It would be a relatively minor feature to add to C IMO

Breaks with longjmp().

I've not done an in-depth analysis but I don't think longjmp is as performant as pushing (and updating) the return stack. Maybe you could do it with assign to our variable + jmp.

Re: Untangling Lifetimes: The Arena Allocator

#92

Post by sfpotter » Tue, Nov 01, 2022, 2:06 AM UTC

abnercoimbre wrote: post #86

sfpotter wrote: post #25

This article is about 10 times longer than it needs to be. Also no need for the dripping condescension. I’m even among the most receptive to what he’s trying to say, but got exhausted after about 20% of the article and had to give up.

We're having Ryan at Handmade Seattle [0] this November to discuss memory management strategies (with other engineers across the memory-safety spectrum.) You might prefer a public, conversational setting at the conference instead of a personal blog post. That said the article made useful technical points. And he wasn't hurling expletives or denigrating any individual. [0] https://handmade-seattle.com/

That’s great! Good luck with your conference.

I hope you can appreciate that there’s room between “technically correct” and “hurling expletives” for some someone to simply dislike an article. I regret my response struck a nerve—it certainly was not meant as an attack on its author.

Re: Untangling Lifetimes: The Arena Allocator

#93

Post by rudedogg » Tue, Nov 01, 2022, 5:58 AM UTC

adamrezich wrote: post #62

sfpotter wrote: post #25

This article is about 10 times longer than it needs to be. Also no need for the dripping condescension. I’m even among the most receptive to what he’s trying to say, but got exhausted after about 20% of the article and had to give up.

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 ow…

> per-frame "scratch" pool allocator

Here's that Jonathan Blow stream if anyone else is curious: https://www.youtube.com/watch?v=ciGQCP6HgqI&t=130s

Re: Untangling Lifetimes: The Arena Allocator

#94

Post by jeltz » Tue, Nov 01, 2022, 12:47 PM UTC

pencilguin wrote: post #72

cryptonector wrote: post #68

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…

It is odd to present arena allocation as a technique for C when it is most conveniently used in C++. C++'s Standard library has numerous accommodations to this method, and the core language definition acknowledges as legitimate constructing new objects over top of undestructed old objects. It has been used as long as C++ existed. Code using it is clean and maintainable. I gather Rust is beginning to accumulate simila…

While it might be more conveniently used in C++ the use of arena allocators in C is ancient and it can be pretty convenient even in C. The PostgreSQL code base for example makes heavy use of arena allocators.