
Memory Management Reference - lfischer
http://www.memorymanagement.org/index.html
======
pcwalton
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.

~~~
geocar
You might find Baker's thoughts on Generational GC interesting[1].

[1]:
[http://home.pipeline.com/~hbaker1/YoungGen.html](http://home.pipeline.com/~hbaker1/YoungGen.html)

~~~
pcwalton
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.

------
Fronzie
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.

~~~
pcwalton
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.

Smart pointers are certainly covered in the glossary:
[http://www.memorymanagement.org/glossary/s.html#term-
smart-p...](http://www.memorymanagement.org/glossary/s.html#term-smart-
pointer)

~~~
Fronzie
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.

~~~
jstimpfle
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).

~~~
imtringued
>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.

