5 ms·
Even resource leaks are still possible. Marking an object in a static array as used is still allocation. Forget to mark it as unused later and it still remains
by notacoward 4y ago
Even resource leaks are still possible. Marking an object in a static array as used is still allocation. Forget to mark it as unused later and it still remains unavailable. Do that enough times and you'll still run out. What this approach does is eliminate unconstrained memory use. Leak-related failures will tend to surface earlier and more predictably, instead of at some distant unpredictable time when the system can't satisfy your program's infinite appetite. And there are resources besides memory.
This approach is still useful, but it's no panacea. It can even leave various kinds of capacity unused, or it can become a tuning nightmare if you try to avoid that. It has long been common in embedded (as others have pointed out) due to the requirements and tradeoffs characteristic of that space, but for general-purpose computation it might not be the tradeoff you want to make when other techniques can solve the same problem without some of the drawbacks.
- hinkley 4y agoWhere this hair gets particularly thin is when you start with an app that uses fixed memory and then you end up in a situation where it works out that running many copies of the code is a solution to a (scalability) problem. Then pre-allocation becomes a problem because you've just locked up a hefty chunk of memory. And that can be a self fulfilling prophecy. One of the problems with memory pools is concurrent access, both by your programming language and the processor, and so it starts looking attractive to spool up a process per task.