(no title)
PythagoRascal | 3 years ago
- https://www.gingerbill.org/series/memory-allocation-strategi...
- https://www.rfleury.com/p/untangling-lifetimes-the-arena-all...
PythagoRascal | 3 years ago
- https://www.gingerbill.org/series/memory-allocation-strategi...
- https://www.rfleury.com/p/untangling-lifetimes-the-arena-all...
moring|3 years ago
That is, the second article basically says: (pre-arena) It would be so easy if we could just allocate everything on the stack, because lifetimes are nestable. But the article doesn't say how to know the required size of the stack in advance, to prevent stack overflows. That was the part I was interested in.
edit: I could read the first article through a proxy, but it also just talks about different allocators. I'd like to achieve what com2kid was talking about: "Allocating all required memory is, IMHO, a great practice for almost any type of program."
throwaway17_17|3 years ago
Pre-allocating certainly requires a system/application designer to consider the most likely worst case resource usage and then enforce that estimate throughout the design.
Further, for systems that have modern memory sized resources (i.e. 16gb and up) the system is designed to work as though memory was a stack and then that stack is allocated from system resources using something like a growable array, or slab style allocator. So that if the estimated wort case usage is reached, the ‘static memory allocation’ can be relocated and enlarged or added onto with a new slab.
Your comments imply the sticking point may be the estimate of program memory usage, and that is a very fact/situational analysis.