This is one of my favorite resources on garbage collection techniques. It's opinionated in favor of the tried-and-true approaches (generational tracing GC), which is a very welcome stance.
All that shows is that, theoretically, one can come up with a system in which generational GC is counterproductive despite a high infant mortality rate. That is not an argument that generational GC is a bad idea in practice, and the article is clear not to make that argument.
In their faq they do seem to step over RAII as an idiom to have scalable and maintainable memory management without garbage collection.
For (semi-) realtime systems, the predictability of RAII is a huge benefit.
RAII is not really a memory management technique per se: it's instead a language feature that can be used to implement smart pointers. Smart pointers can implement reference counting, which is a form of garbage collection.
That's a limited view. One could very well make it's own class with malloc()/free() in the constructor/destructor, without exposing any pointer like interface. This can be done without reference counting, contrary to what the faq suggests.
the C++ STL takes away the burden of 'hard to implement'. It's definitely hard to do right, but the STL has solved that problem.
I'm sure garbage collection has it's place and use, but the site seems a bit biased against alternatives.
Garbage collection definitely has it's scaling challenges for large code-bases.
pcwalton is right. RAII is just a language semantics to make memory management implicit.
(I feel a little bit cynical today and will say it's typical to C++'s attitude (as opposed to e.g. C): Let users make overcomplex programs more easily, by papering over all the insanity, instead of forcing them to make a clean design).
If there's anything like "memory management" in RAII, then it's the idea of deallocating objects in the reverse order of their allocation. That hardly deserves a note, though, since it doesn't say anything about how the memory is allocated.
(And as usual with OOP, you end up with terrible inefficiencies (too much allocation in this case), since the program is split into needlessly isolated parts in a futile attempt to make them "self-contained". In the end, what that does is also make everything less efficient and more complicated. And redundant, if you care to look at what actually happens as opposed to what the programmer writes).
>And as usual with OOP, you end up with terrible inefficiencies
That is not a property of OOP. Counterexample: C++ is OOP and it's not inefficient.
It's a property of having no control over the memory layout and no stack allocation.
If Java gets value types it's efficiency would massively increase while still remaining OOP.
8 comments
[ 5.0 ms ] story [ 24.3 ms ] thread[1]: http://home.pipeline.com/~hbaker1/YoungGen.html
Smart pointers are certainly covered in the glossary: http://www.memorymanagement.org/glossary/s.html#term-smart-p...
the C++ STL takes away the burden of 'hard to implement'. It's definitely hard to do right, but the STL has solved that problem.
I'm sure garbage collection has it's place and use, but the site seems a bit biased against alternatives. Garbage collection definitely has it's scaling challenges for large code-bases.
(I feel a little bit cynical today and will say it's typical to C++'s attitude (as opposed to e.g. C): Let users make overcomplex programs more easily, by papering over all the insanity, instead of forcing them to make a clean design).
If there's anything like "memory management" in RAII, then it's the idea of deallocating objects in the reverse order of their allocation. That hardly deserves a note, though, since it doesn't say anything about how the memory is allocated.
(And as usual with OOP, you end up with terrible inefficiencies (too much allocation in this case), since the program is split into needlessly isolated parts in a futile attempt to make them "self-contained". In the end, what that does is also make everything less efficient and more complicated. And redundant, if you care to look at what actually happens as opposed to what the programmer writes).
That is not a property of OOP. Counterexample: C++ is OOP and it's not inefficient. It's a property of having no control over the memory layout and no stack allocation. If Java gets value types it's efficiency would massively increase while still remaining OOP.