Question

This question is a follow up to my previous Java GC question: Java Garbage Collector clarification

This question is also referring to the same article.

I’m a little confused on why the stop and copy method for defragmenting object heap allocation is so commonly used. Yes it defragments the heap however it seems like there is tons of overhead because basically you cut the total amount of heap size in half. Also you need to copy ALL the live objects when one half has run out of space.

Other than defragmentation is there any other fundamental reason why ‘stop and copy’ is better than say ‘mark and sweep’?

Answer 1

Actually, fragmentation is fundamental, and the ability of some GC to defeat it is a considerable asset.

The stop-and-copy algorithm used to be popular in GC implementations because:

1. it is simple to implement;
2. it automatically defragments memory;
3. its running time is proportional to the amount of live objects, which makes it asymptotically very efficient.

More modern GC, including those used in Java, use much more complex strategies because they want to make short pauses (rather than making total GC time low, they prefer never to stop the application for a long time, because pauses are bad for interactivity), to interact more cleanly with caches and virtual memory, and to benefit from systems with multiple CPU.

The Jones and Lins book is a must-read for whoever wants to understand garbage collection.