3 ms·

GC enthusiasts say this, but I have never seen it actually be true. The reason is that whoever wrote the GC for your language has to solve an extremely general

• wiz21c 10y ago
  >>> A memory management system for a particular program only has to solve the problems of that program, which is a tremendously simpler thing to do. I don't like to sound rhetorical, but writing a memory management system for anything non trivial (that is, a scenario where you allocate and deallocate memory) quickly becomes a difficult problem. Besides, could you give us an example ? I'd like to know about it. My example is a video game where we were allocating thousands and thousands of small stuff and deallocating it. Soon you end up with a fragmented memory where you can't allocate big chunk of memory...
  • vvanders 10y ago
    That's almost the canonical example. Say for a particle system you use a fixed-block allocator that's the size of your particles. Now your allocations are quick since you don't have to do fitting and you don't fragment memory since they're all clumped together. Other common trick in video games is to have a single-frame arena allocator for objects that are transient frame to frame. You just move a pointer forward and reset the pointer at the end of the frame.
  • aschampion 10y ago
    That's an odd example, given most video games are written in memory managed languages for performance reasons. Typically an allocation pool would be used for that case because there's some bound to the number of simultaneously allocated objects and each object has a homogeneous memory footprint. It's also odd because you're replying to a well-known game designer. That said, there are allocation-heavy workloads for which GC is well suited.
    • wiz21c 10y ago
      >>> It's also odd because you're replying to a well-known game designer. Authority position ! :-) I worked on optimizing the Outcast game 3D engine (ok that was around 20 years ago). And I clearly remember other devs in the team struggling with memory allocation. In the end, they sorted it out without resorting to a full fledged GC. But since our case was simple (loading resources for building a world, then releasing resources that are not useful anymore), I concluded that it's not easy. In the end, it all depends on the nature of the problem, and one can optimize for any of them (as it is customary in video games). I know that.
  • wahern 10y ago
    > I don't like to sound rhetorical, but writing a memory management system for anything non trivial Writing a generic memory management system is non-trivial. Designing and implementing a memory management strategy with an understanding of the application semantics--especially when you can modify the semantics, or enlarge or narrow the relevant context, as appropriate--is much easier. Trivial in many cases. Writing a GC for the JVM is difficult because the 1) JVM has far fewer degrees of freedom, and 2) they have to solve a much more difficult problem. All those awesome-sounding automatic optimizations JIT compilers can implement pale in comparison to the overall difficulty of the underlying problem. By way of analogy, look at formal software verification. The underlying computational complexity of the algorithms are extremely costly. The only way to make it work is by using a human to refactor the big problems into many smaller problems, including smaller problems that encapsulate other smaller problems. Only humans can do that, and it will be that way for quite some time. Manual memory management is the same way--a human can do better than a generic collector because only the human can refactor the program. Only a human can say, "this part is too complex, with too many lifetime and ownership interdependencies, so I'm going to refactor it so it's easier to use a more elegant memory management strategy". Generic collectors like those in the JVM can't do that--they have to work with the software they're given. If you're having trouble with memory management, perhaps it's because you haven't yet figured out that you don't need to play by the same rules as an automatic garbage collector. And you certainly don't need to be, nor should you be, restricting yourself to a malloc/free-like interface.