• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

What is the real benefit of Generational Garbage Collector?

 
Ranch Hand
Posts: 96
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

I don't understand the real benefit of a generational garbage collector. As I understand, the generational garbage collector divides heap memory in different region and the young generation region (Eden region) is visited more frequently than other region. The purpose is to REDUCE THE TIME NEEDED to collect the unused objects because most of the objects have a short life.

However, the GC still have to traverse ALL THE OBJECT TREE from the root set and visit all the objects, even if these object are in older region (tenured region). How can the time be reduced compared to a garbage collector which does NOT use generational model? Because in a non-generational GC, the GC also has to traverse ALL the object tree from the root set.

Thank you very much.
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Swerrgy Smith wrote:
I don't understand the real benefit of a generational garbage collector. As I understand, the generational garbage collector divides heap memory in different region and the young generation region (Eden region) is visited more frequently than other region. The purpose is to REDUCE THE TIME NEEDED to collect the unused objects because most of the objects have a short life.

However, the GC still have to traverse ALL THE OBJECT TREE from the root set and visit all the objects, even if these object are in older region (tenured region). How can the time be reduced compared to a garbage collector which does NOT use generational model? Because in a non-generational GC, the GC also has to traverse ALL the object tree from the root set.



It has been a while... so hopefully, I remembered everything correctly.

The new generation collector is a copy collector. How it works is to treat the heap as two halves. During collection, anything that is reachable is moved from the current half to the other half (and all the references in the JVM has to be fixed). This means that it is really expensive when an object is reachable. On the other hand, when an object is not reachable, it is really easy to deal with -- just ignore it, as it will be wipe because it is in the half that will be reused.

Hence, it is very good for the new generation, as most newly created objects are very short lived; but it is bad for the tenure generation, as it will be constantly moving the objects between the two halves. And moving an object is much much more expensive than marking an object as reachable, as the GC has to find all references and fix it.

Also, the parallel version of the new generation collector is ... well... parallel. This mean that it will use all the cores in the machine, making it really fast at determining reachability.


The tenure generation collector is a mark and sweep collector. It is not as fast as the new generation collector, but it uses the heap more efficiently -- as it just compacts the heap. It is also not as efficient for two other reasons; it has to deal with the majority of objects which are reachable (not collected), and it is not parallel. However, it is concurrent -- meaning that the program does not have to stop while it is collecting. This means that the GC can take it time, with not too much of an impact on the application -- to probably collect a smaller amount than the new generation would collected.

Also, two more reasons why this collector is good for the tenure generation... first, since it is a compacting collector, objects slowly move towards the beginning, until it is an area where everything is always reachable, hence, not being collected, hence, not being moved. Second, this collector is less efficient when an object is not reachable. Not reachable objects creates a hole, and holes needed to be close via compaction, which means objects needs to be moved.

Henry
 
Henry Wong
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here is an interesting data point, which may give more value to having a generational garbage collector... I used to work for Azul Systems, and of course, they are famous for their pauseless garbage collector. This GC is concurrent, parallel, *and* generational. And I got to talking to one of the engineers about it...

My question was, if the GC operation is not stop-the-world, and the appliance can throw a ton of cores at it (hence, fast), why would it need to be generational? Well, the answer that I got as feedback was ... The GC may not be stop-the-world, but certain threads will stop. Specifically, any thread that is waiting for memory running the "new" operator (ie. doing memory allocation). These threads will have to wait for the completion of a GC cycle before it can get the memory requested. This, of course, also means that the application is generating a ridiculous amount of garbage, as the Azul appliance doesn't wait for an out of memory condition before running the GC.

Anyway, while the GC doesn't need to be generational, having it as such gives more consistency. Applications that is consuming *and* generating a ridiculous amount of garbage tend to have a ridiculous amount of instances with very short lifespans. By having it as generational, it allows the appliance to collect those ridiculous amount of memory, and do it with a shorter GC cycle time. In other words, it may be more efficient to collect as non-generational, but it won't be as consistent. The threads that are waiting for memory will wait shorter times with a generational collector. All other threads, that are not waiting for memory, don't even noticed that a GC cycle is happening.

Henry
 
Swerrgy Smith
Ranch Hand
Posts: 96
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank Henry for your replies.

I also found a very helpful answer to my question here:
http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html

As I understand from the article, the most EXPENSIVE operation is not to mark the objects (i.e. traversing the object tree) but it's the compacting process.
Using Generational GC can help optimize the compacting process. Instead of compacting the WHOLE heap memory each time, the GC just needs to move all the "survived" objects from the Eden region to the Survive regions (first S0, then S1). After this "moving step", the Eden region, which is the busiest region, is clear and ready to use.

In this model, the compacting process is done much less frequently and only with the old generation region.

Please correct me if I'm wrong!

Thank you all.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic