Java VM: Trying a new Garbage Collector for JDK 7
Filed under: java javase jdk7 vm on Wednesday Nov 12, 2008
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.
Posted by dannycoward
| Comments[23]
Great :)
Posted by Matto on November 12, 2008 at 11:58 PM PST #
This is awesome stuff.
Keep up the good work. :-)
Posted by Mayuresh Kathe on November 13, 2008 at 09: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 09: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 09: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 07:34 PM 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 11: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 11: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 12:37 PM PST #
@Gili
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 03:30 PM 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 19, 2008 at 07:13 AM 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 11: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 02:18 PM 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 25, 2008 at 03:26 AM 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 12:35 PM 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 12:42 PM PST #
关注！
Posted by Bruce on December 04, 2008 at 06:32 AM PST #
G1 can support larger Memory ,such as 32G(or above) Memory?
Posted by Myers on December 10, 2008 at 11: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 10:39 AM PST #
Works for me dude
www.web-privacy.pro.tc
Posted by Jack Wright on January 06, 2009 at 11: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 12:44 PM 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 11:24 AM PST #
:::::::::::::;;;;L
;
L'
Posted by 196.3.183.73 on March 17, 2009 at 09:23 AM PDT #
Hi
what all VM options are supported by G1 for GC tuning?
How to specify the throughput and pause time goal?
Regards
Kapil
Posted by kapil on April 24, 2009 at 12:31 AM PDT #