I wrote some specifics in this thread over a few comments but that and the type system are complex. It can be a talk and writing short post probably will satisfy no one
If you want to get even more precise, call it automatic dynamic memory management. Automatic static memory management would be something like Rust's scope-based memory reclamation via ownership.
No, and that would make a great empirical study. (Maybe there has been one! I should check ISMM over the past decade, someone may have done it already.)
From first principles, the biggest difference is that manual memory allocation can't move live objects around. But manual memory managers do still have the ability to be smart on deallocation, to the point that calling free will sometimes cause things to happen that would be similar in a garbage collector.
Nope, you're the one missing the point, just because a language has some kind of automatic memory management, it doesn't mean C like features for deterministic manual memory management, or any other kind of manual resource management aren't available.
Totally, that could absolutely be the case. But it probably won't be. The reality is that most C programs do use manual memory management, by a very wide margin.
It somewhat depends on what you mean by "manual memory management", I am not sure it has a definition beyond garbage collectors being outside it -- gray areas exist. Using that tool requires some mastery of its idioms and rules regardless. Memory management is much more complicated than safely acquiring and releasing memory for object instantiation, or even accessing it safely. At least in C++, you can build safe memory abstractions for almost any resource model, including some pretty unusual ones that show up in performance-sensitive applications. In C it is significantly more difficult.
If you are building large-scale, high-performance infrastructure, manual memory management is to some extent unavoidable. In many database engines, for example, memory lifetimes and object lifetimes are distinct and independent concepts. There are classes of algorithm optimization that require strict and explicit understanding of the address space your process claims to own. The silicon does not respect the object model of your programming language, but you still need the silicon to manipulate memory directly (as it understands it) for performance reasons. This seems complicated but understanding it well enough to leverage it has significant performance implications.
That said, I don't see a lot of heap allocation in things like database engines. Almost all the memory used is allocated and deployed at bootstrap, and most of the remainder is on the stack. Not a lot of attack surface for memory management problems to show up. Other applications may be different.
Maybe for prototypes or small scripts but disagree otherwise. The promise of automatic memory management is that you don't have to think about memory.
But the second you don't think about memory you are doomed to write bad code anyway. Maybe because of performance but most probably due to architecture. To have a language that forces you to think about memory is not a curse, it is a blessing.
reply