garbage collection - Java GC: why two survivor regions?

Question

For Sun/Oracle's JVM, I've read that the GC algo divides new generation into one Eden region and two survivor regions. What I'm wondering about is, why two survivor regions and not just one? The algo can keep ping-ponging between Eden and just one survivor region (the way it currently does between two survivor regions); or are there any shortcomings to this approach?

Answer 1

I believe JRockit's GC implementation works more like you suggest, with just a single eden and single survivor space, but don't quote me on that.

The reason for the HotSpot JVM's two survivor spaces is to reduce the need to deal with fragmentation. New objects are allocated in eden space. All well and good. When that's full, you need a GC, so kill stale objects and move live ones to a survivor space, where they can mature for a while before being promoted to the old generation. Still good so far. The next time we run out of eden space, though, we have a conundrum. The next GC comes along and clears out some space in both eden and our survivor space, but the spaces aren't contiguous. So is it better to

1. Try to fit the survivors from eden into the holes in the survivor space that were cleared by the GC?
2. Shift all the objects in the survivor space down to eliminate the fragmentation, and then move the survivors into it?
3. Just say "screw it, we're moving everything around anyway," and copy all of the survivors from both spaces into a completely separate space--the second survivor space--thus leaving you with a clean eden and survivor space where you can repeat the sequence on the next GC?

Sun's answer to the question is obvious.