Java VM: Trying a new Garbage Collector for JDK 7

Like using the living room as the kids play area, tidying up, or garbage collection, is an integral part of life in the JVM. Except that the kids are applications and the toys on the floor the objects they create. But unlike in your living room, these kids don't sleep, are always playing with something, will scream if they have to wait while you tidy up, and will get seriously, seriously mad if they lose a toy. So how can you organize the mess they make without disrupting the game ?

The HotSpot team has been quietly working on a new algorithm, called Garbage First, for tidying up the memory space in the JVM while the kids are playing, as a replacement for the existing parallel and concurrnet mark sweep collectors. By dividing the living rooms into equal squares, it turns out that for most games, many of the squares contain unused toys that can be safely put away. By picking the low hanging fruit in this way, the new collector can work more predictably, and be given directives to operate within given time slices, which it can follow most of the time. And of course, being fully concurrent, its ready made for multiple cores.

And you can try it out because they quietly slipped it into the latest build of JDK 7.

Tony was interviewed at length about it at JavaOne 2008, and you can read more descriptions by Kirk, Alex, Charles, or get the full description in this paper.

Great :)

Posted by Matto on November 12, 2008 at 03:58 PM PST #

This is awesome stuff.
Keep up the good work. :-)

Posted by Mayuresh Kathe on November 13, 2008 at 01:09 AM PST #

I'll give it a try as soon as JDK7 builds are usable. It looks like not all the Java6 update10 changes have been folded in yet and the last time I tried running Netbeans under it a lot there were a lot of annoying cosmetic bugs.

Glad to hear about G1 though. Very cool! Keep up the good work.

Posted by Gili on November 13, 2008 at 01:21 AM PST #

PS: Is G1 the default garbage collector in JDK7 or do you need to enable it somehow?

Posted by Gili on November 13, 2008 at 01:36 AM PST #

This is great! I am all for Java performance gains - smaller memory footprint, speed, simplified algorithms, etc. I am hoping in the IT industry that we see more focus on fixing problems before adding new features. This is a move in the right direction.

Posted by Jesse Chan on November 13, 2008 at 11:34 AM PST #

While I'm generally happy with the current GC functionality, I do have one hope for newer collector designs. Would it be possible to work (optional) dynamic heap resizing support into them? I'm not sure what the configuration options should look like... but at least an option to allow the max to be configured to unlimited (grow as needed) would be well received.

Allowing the heap to shrink after a while would also be nice. And while I'm on this topic... :-) Just an option to set the maximum based off of the physical system RAM would be welcome also (max heap size = system-ram-size - 256MB, for example).

If some of these features are already implemented and I've just missed them I'd love to hear that also. Great to hear about the progress on garbage collection and JDK7 nonetheless...

Posted by Dwayne Parks on November 14, 2008 at 03:42 AM PST #

I agree with Dwayne, many people have been requesting unlimited heaps and for the JVM to return memory to the OS.

Posted by Gili on November 14, 2008 at 03:43 AM PST #

Is G1 really available in b39? I saw those bugfixes but I thought they were just preparation stuff... because b39 was promoted in Nov-06, but only in Nov-10 Sun did the massive G1 putback (73 changesets, OMG!) in the jdk7 repository. Just to be picky - and too lazy to download and test ;-)

Posted by Osvaldo Pinali Doederlein on November 14, 2008 at 04:37 AM PST #


Its not the default yet, we still have more work to do on it. You can enable it with:-

-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC

Have fun !

- Danny

Posted by Daniel Coward on November 17, 2008 at 07:30 AM PST #

Indeed, please add a unlimited heap option! It is the number one reason why have to tell our clients "yes we know that you have enough memory, but we are using java."

Posted by Chrisitaan on November 18, 2008 at 11:13 PM PST #

My congratulations to HotSpot team, indeed. You are doing a good job.
Just one question, what about "PermGen Out of Memory" ?

Posted by trunikov on November 19, 2008 at 03:10 PM PST #

I tried this with our application, however the GC pause times doubled compared with ConcurrentMarkSweep. Even with the max pause time set to 1 ms.
Hopefully this will improve. :)

Posted by Peter Lawrey on November 22, 2008 at 06:18 AM PST #

I tested G1 from b40. Tests with small apps, like Java2Demo, show similar performance as CMS but higher memory usage, certainly due to G1's fine-grained heap partitioning and higher cost in remsets. Probably not a good choice to be default GC on consumer-oriented HotSpot Client. But that was expected, if I understand correctly G1 is all about soft-realtime and scalability, so there's a cost in throughput and/or heap size.

Then I tested in on a large, very memory intensive real world app (700Mb peaks, many gigabytes of churn, ~40 minute-long batch transaction) and it crashed with an access violation. I reported this to Sun - bug 6775807 (not yet public). So it seems G1 has some way to go before it can be performance-benchmarked, let's give it time... considering that the code is crashing in the very first stress-test I throw at it, I guess it should be still in the stage "shock-full of debug/diagnostics code" so benchmarking won't be meaningful at this time. But I will keep stress-testing G1 once Sun fixes this bug, will report performance findings when I have them.

Posted by Osvaldo Pinali Doederlein on November 24, 2008 at 07:26 PM PST #

Yes G1 has a lot of promise, but its still early days.
I tried using it to run IntelliJ and it crashed almost immediately.
I will be looking for lower pause times. Curiously, the ParallelGC has the lowest pause times, but also the longest. :}
We use Java for trading systems and 1 ms is a long time to wait for a GC. Performance (throughput) is less of an issue. If we could turn off the gc for brief periods, we would. i.e. under application control.

Posted by Peter Lawrey on November 25, 2008 at 04:35 AM PST #

@those of you trying it out

Thanks for being brave - its definitely in the experimental phase, and thanks for posting what happened when you tried it. We're watching :)

Over the coming months, now that its in the openjdk codebase, you should see updates on what's there, as it gets more robust and we start to tune it.

Posted by Daniel Coward on November 25, 2008 at 04:42 AM PST #


Posted by Bruce on December 03, 2008 at 10:32 PM PST #

G1 can support larger Memory ,such as 32G(or above) Memory?

Posted by Myers on December 10, 2008 at 03:05 PM PST #

Your kids don't scream if they have to wait for - well, anything, and don't get mad if they lose something? You should be writing a parenting blog, not a software one :)

I don't suppose this new GC will do anything about those awful classloader PermGen problems that plague application servers, will it?

Posted by Anonymous on January 06, 2009 at 02:39 AM PST #

Works for me dude

Posted by Jack Wright on January 06, 2009 at 03:02 AM PST #

Hopefully can solve the class loader PermGen problems for the system which needs to create new mass JSP pages dynamically.

Posted by Mark on January 06, 2009 at 04:44 AM PST #

I found many issues with the GC when it comes to managing Strings in a web app. Does the new GC manage Strings in a better way?

Posted by KHALID EL-HARMASSI on January 09, 2009 at 03:24 AM PST #


Posted by guest on March 17, 2009 at 02:23 AM PDT #

what all VM options are supported by G1 for GC tuning?
How to specify the throughput and pause time goal?


Posted by kapil on April 23, 2009 at 05:31 PM PDT #

By dividing the living rooms into equal squares, it turns out that for most games, many of the squares contain unused toys that can be safely put away.

Posted by replica rolex on December 27, 2009 at 01:33 PM PST #

So are they implementing a new algorithm in this version of garbage collector?

Posted by vidrio quimica on April 30, 2010 at 10:58 AM PDT #

Your kids don't scream if they have to wait for - well, anything, and don't get mad if they lose something? You should be writing a parenting blog, not a software one :)

Posted by mp4 on September 18, 2010 at 03:39 PM PDT #

quindi hanno un prezzo più elevato. Molte persone sono stupiti a prezzi nostra replica orologi Breitling sono disponibili e vogliono avere uno per ogni giorno della

Posted by telefonino cellulari on October 29, 2010 at 05:12 PM PDT #

Well in my opinion I think that its all about how you educate your kids. Mine never leave a mess, they know they have to clean their own stuff!

Posted by turks and caicos villas on November 30, 2010 at 06:30 PM PST #

G1 should use incremental collection until its adaptive logic (or whatever it's doing under the hood) has kicked in for the classes in question.
What I'm observing is a 'stickyness' at the beginning just like non-incremental but stabilization after a period. With incremental gc -Xincgc you get that from the get-go, which is a requirement for client apps.

Posted by G1 should use incremental until ... on February 02, 2011 at 09:20 PM PST #

Post a Comment:
  • HTML Syntax: NOT allowed

A blog all about Java in all its flavors on all client platforms from smartcards to desktops and everything inbetween.


« July 2016