Untangling Lifetimes: The Arena Allocator

Untangling Lifetimes: The Arena Allocator(rfleury.com)

31 points by _ktnd 2 years ago | 5 comments

Great article. I haven't yet had the opportunity to use arena allocators, but the article is a solid rundown of why their useful and how they're implemented

vsnf 2 years ago |

The author seems bitter about C having lost its vaunted position as the language of choice.

carlmr 2 years ago | |

Very much so

>The perception that manual memory management is difficult to do, difficult to do correctly, and thus inherently bug-prone and unstable is common.

Yes, not just the perception. Microsoft and Google did large enough studies with the highest paid engineers in the world and they came to that conclusion. There's evidence behind it.

After working with C and C++ for over a decade, I still have to see a non-trivially sized/non-hobby project, that didn't have a vast amount of memory management bugs discovered later, with a lot of compute time for tooling and manual debugging involved.

I'd say a single talented programmer can manage memory manually mostly correctly.

But not a group of programmers of varying levels, as you will always find them in a larger project.

>If there is no organizing principle around managing these relationships and their corresponding lifetimes, through a number of subtle mistakes

Here the author seems to almost grok this. The only realization missing is that if you're not the dictator of this project, you won't be able to enforce your style top-down and this mess is almost inevitable.

Of course allocation and deallocation is also not the only memory management issue. The author seems to ignore mutability issues, array out of bounds issues, etc. which are also memory management issues C doesn't help you with. Quite often worse than a memory leak.

Despite his ranting detracting from the main point of the article, I think it's quite a solid introduction to arena allocation.

I've found it quite useful in hard real-time systems where you need more than the usual stack memory for dynamically sized arrays (within bounds).

layer8 2 years ago | |

It’s an unexpected change that happened in the last few years. While everyone knew C had its quirks, it was rarely seen as impractical or somehow an unreasonable language choice before that. And when regarded that way, then usually in preference of C++.

pjmlp 2 years ago | | |

Guess which language C.A.R. Hoare means on his 1980's Turing Award speech.

"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."