Discussions

News: Q&A with Holly Cummins on Java Garbage Collection

Bookmark and Share Get thread feed

  1. Q&A with Holly Cummins on Java Garbage Collection (9 messages)

    • Posted by: Nitin Bharti
    • Posted on: November 20 2007 11:56 EST
    In this interview, Dr. Holly Cummins, noted IBM garbage collection tuning specialist, discusses the benefits of Java garbage collection and a number of other topics all to do with Java heap space, garbage collection and other matters that can be seen a activities that degrade application performance and throughput. From the interview:
    Kirk Pepperdine: In terms of the garbage collection models, memory models within the IBM virtual machine, up until 1.4 they were quite divergent from the Sun generational model and the JRocket generational model. Can you describe to us what's changed and maybe some of the reasoning behind those changes? Holly Cummins: Sure, as of 1.5 we've got 3 or 4 policies, depending on how you count it. We've got the standard mark-sweep concurrent. We've got the standard mark, sweep not-concurrent. And we do find in most situations, that does actually give better throughput than the generational policy, which is why it is the default. But in 1.5, we do introduce the generational model, and so it's just got two generations because we found when we did our performance tuning that you got the greatest benefit from generations by having just two. And some of the downsides of generational policy you avoided by having just two generations. And so you've got in the younger generation you've got a copying collector, which is extremely fast, and gives you very fast allocation, and very fast application access. And then in the older generation it's a concurrent collector and so we found with our gen-con policy the pause times tend to be quite short because in the nursery, the nursery is pretty small, it can, it collects pretty quickly, and then if you do a full collection, it's still a pretty quick collection because it's concurrent, and so it's running in the background for most of the duration of the collection.
    See also: Do you know how to Optimize your JVM? - A video tech brief with Dr. Cummins.
    Reply to this

    Threaded Messages (9)

  2. Re: Q&A with Holly Cummins on Java Garbage Collection[ Go to top ]

    Collecting garbage is not prestigious thing to do.
    Reply to this Reply to original

  3. Re: Q&A with Holly Cummins on Java Garbage Collection[ Go to top ]

    Read about garbage collection at http://www.java4all.info/articles/corejava/garbage-collection-java.html
    Reply to this Reply to original

  4. Re: Q&A with Holly Cummins on Java Garbage Collection[ Go to top ]

    Sorry, this appeared on TSS in October. See here
    Reply to this Reply to original

  5. Re: Q&A with Holly Cummins on Java Garbage Collection[ Go to top ]

    Sorry, this appeared on TSS in October. See here
    Yeah, not another thread focusing on blue hair and gender instead of relevant topics.
    Reply to this Reply to original

  6. Re: Q&A with Holly Cummins on Java Garbage Collection[ Go to top ]

    Sorry, this appeared on TSS in October. See here


    Yeah, not another thread focusing on blue hair and gender instead of relevant topics.
    No, it didn't - there were two interviews. One's a video, the other is a podcast. (This one's the podcast.)
    Reply to this Reply to original

  7. Re: Q&A with Holly Cummins on Java Garbage Collection[ Go to top ]

    Sorry, this appeared on TSS in October. See here
    Eugene did the video interview and I did this interview. Two different interviews done at different times on her specialty. Kirk
    Reply to this Reply to original

  8. JVM commits 230 MB on any flavor of unix[ Go to top ]

    use JMX, ps aux whatever you choose. JVM 1.5 uses 280 MB of VSS committed virtual memory. JVM 1.6 uses 230MB. Linux and solaris is the worst platform for Java these days. Same VM running same nothing app commits a total of 30MB on Windows. This is a JVM doing nothing but printing a sysout every 10 seconds. Bug reported to SUN nothing done. So dont talk to me about the heap until you can explain this. Because its killing unix based java servers!
    Reply to this Reply to original

  9. Re: JVM commits 230 MB on any flavor of unix[ Go to top ]

    JVM 1.5 uses 280 MB of VSS committed virtual memory.
    JVM 1.6 uses 230MB. Linux and solaris is the worst platform for Java these days.
    Same VM running same nothing app commits a total of 30MB on Windows.
    Can you cite a reference or at least give a link?
    Reply to this Reply to original

  10. Re: JVM commits 230 MB on any flavor of unix[ Go to top ]

    use JMX, ps aux whatever you choose.

    JVM 1.5 uses 280 MB of VSS committed virtual memory.

    JVM 1.6 uses 230MB. Linux and solaris is the worst platform for Java these days.

    Same VM running same nothing app commits a total of 30MB on Windows.

    This is a JVM doing nothing but printing a sysout every 10 seconds.

    Bug reported to SUN nothing done. So dont talk to me about the heap until you can explain this. Because its killing unix based java servers!
    Well, Holly Cummins works for IBM, not Sun so this is a little misplaced but what you are seeing may not be a bug or a problem. Have you looked at the documentation for the JVM and determined what the default minimum heap size? You can set this and the maximum heap size if the heap is too large for your app. It might just be that Sun decided that most apps on the server were using more heap than the old default of 32 and to improve the start-up time they went with a higher default.
    Reply to this Reply to original