Java GC: why two survivor regions?

Young Generation : It is place where lived for short period and divided into two spaces:

Eden space : New objects will be allocated in the memory pool. The assumption is that most object get dereferenced and become unreachable soon after their creation. Objects not being dereferenced will be copied by the new generation garbage collector into the survivor spaces. They may get copied n some special cases directly into the old generation pool.

Survivor spaces: These two small spaces keep the surviving objects of a young generation garbage collection. Surviving objects will be copied for a (small) number of times from one survivor into the other. This allows to harvest our more dereferenced objects.

Old generation: The largest memory pool which should keep the long living objects. Objects are getting copied into this pool once they leave the survivor spaces.

Permament generation: This fairly unknown pool keeps the information of all the classes. It doesn't need any attention for most applications. It may need to be adapted for some applications with many classes. It may need some attentention as well if the application permanently loads and unloads classes.

Other advantages:

  • Memory fragmentation
  • It improves GC performance

Please find the following links for more details which can help you understand more

http://www.scalingbits.com/javaprimer

http://java.sys-con.com/node/84695


The role of two survivor spaces gets reversed after the operation of a minor garbage collection

The two survivor spaces. These hold objects that have survived at least one minor garbage collection but have been given another chance to become unreachable before being promoted to the old generation. Only one of them holds objects, while the other is most of the time unused.

During the operation of a minor garbage collection, objects that have been found to be garbage will be marked. Live objects in the eden that survive the collection are copied to the unused survivor space. Live objects in the survivor space that is in use, which will be given another chance to be reclaimed in the young generation, are also copied to the unused survivor space. Finally, live objects in the survivor space that is in use, that are deemed “old enough,” are promoted to the old generation.

At the end of the minor garbage collection, the two survivor spaces swap roles. The eden is entirely empty; only one survivor space is in use; and the occupancy of the old generation has grown slightly. Because live objects are copied during its operation, this type of garbage collector is called a copying garbage collector.

Source : above are the excerpts from page 83 of Java Performance, by Charlie Hunt and Binu John.


All the current answer talk about memory fragmentation, this is also another reason to have generations in GC.

The runtime records all “old objects” that point to “new objects”, this is done every time a “pointer” field is updated. Then when a “minor” GC is done, only “new” objects need to be scanned.

Over the years it has been found that just have “new” and “old” is not enough, and it is good to have a 3rd generation that is “middle aged”.


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.