I rarely complain about someones english, but that link is very hard to read.

"Key point of generational GC is what it does need to collect entire heap each time, but just portion of it (e.g. young space)."

"This principle is based on hypnotize that most object “die young”, i.e. majority of objects are becoming garbage shortly after being allocated."

> you still are susceptible to your heap becoming fragmented and run the risk of requiring a full GC to compact the heap.

But isn't the heap fragmentation a much bigger problem with malloc style memory management?

No, because you can allocate from different arenas if you need to. Using plain malloc may lead to fragmentation, but there's no law requiring you to use a single lowest common denominator allocator for your entire program.

That doesn't contradict his observation. Changing your program to use custom memory allocators can solve fragmentation issues, but that's a much bigger step than the changes required to avoid too many (or too expensive ) full GCs (i.e. tuning the garbage collector directly, gettting "permanent" data out of the garbage-collected heap, minimizing mutations so there's less to scan...).

The only times I've had difficulty solving a fragmentation problem was because a GC was involved, and rewriting the code in an effort to trick some enormous black box into doing what I wanted was a lot more difficult than just writing code that did what I wanted in the first place. ymmv.

I guess in theory fpgeek is right, and his great-grandparent post is in the vein of what I thought of answering. But I guess in practice tedunangst is more right at the moment.

I'll welcome better garbage collection.