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
>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).
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++.
koshergweilo|1 year ago
vsnf|1 year ago
carlmr|1 year ago
>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|1 year ago