BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Presentations Understanding Java Garbage Collection and What You Can Do about It

Understanding Java Garbage Collection and What You Can Do about It

Bookmarks
01:31:36

Summary

Gil Tene explains the workings of a garbage collector: terminology, metrics, fundamentals, key mechanisms, classification of current GCs, the “Application Memory Wall” problem, and details Azul C4 GC.

Bio

Gil Tene has been involved with virtual machine technologies for the past 20 years and has been building Java technology-based products since 1995. He co-founded Azul Systems in 2002, where he pioneered Pauseless Garbage Collection, Java Virtualization, and various managed runtime and systems stack technologies that deliver the industry's most scalable and robust Java platform.

About the conference

SpringOne 2GX is a one-of-a-kind conference for application developers, solution architects, web operations and IT teams who develop business applications, create multi-device aware web applications, design cloud architectures, and manage high performance infrastructure. The sessions are specifically tailored for developers using the hugely popular open source Spring technologies, Groovy & Grails, and Tomcat. Whether you're building and running mission-critical business applications or designing the next killer cloud application, SpringOne 2GX will keep you up to date with the latest enterprise technology.

Recorded at:

Dec 05, 2011

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Slides download

    by Asgeir Nilsen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The download link for the slides doesn't work.

  • So what can you do about it?

    by Joe Adams,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    This is a great presentation on "Understanding Java Garbage Collection" but not "and what you can do about it" In fact, the only piece of advice it has is don't use finalizers if you can avoid it. But I don't think many people use finalizers anyway.

  • Re: So what can you do about it?

    by Barry Kelly,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Joe - if that's the only piece of advice you got out of it, then I think you probably didn't understand what you watched.

    To start with, there was advice about doubling memory to halve GC CPU usage, as a rule of thumb.

    But more importantly, understanding how the GC works indirectly helps you understand what you can do to affect it. For example, the generational hypothesis, that objects die young, directly affects how you architect your application: when you allocate an object, it should logically fall into one of two buckets: something transactional (e.g. associated with a server request or a UI event loop iteration) and ephemeral; or something long-lived, which is going to be rooted by the longer-term heap. The worst case is so-called "mid-life crisis", objects which live a reasonable amount of time and then die; think things like caches that get invalidated only after a few GC cycles have promoted them. They are expensive to collect; some kind of pooling strategy may pay off for caches, perhaps storing your caches in a serialized format in byte arrays, and pooling those byte arrays.

    But if you're looking for a laundry-list of tips and techniques, I think this is the wrong place. Such a cargo-cult approach would be a waste of Gil's time.

  • Re: Slides download

    by Howard Green,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Asgeir,

    Please try the download again -- looks like it is working fine. Be aware that the PDF is around 15 MB and will take a couple of minutes.

  • Great talk

    by Jude Paul,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Great talk; very informative. A couple of questions though:

    1. Gill told - a) Your process can be concurrent but not parallel b) Your process can be parallel but not concurrent c) It can be both.

    I think I understand a & c but b baffles me - isn't something parallel intrinsically concurrent?

    2. He talks about heap sizes in excess of 10G all the way up to 100G. Aren't there limitations on the amount of memory a single process can be allocated based on the OS/Hardware it runs on?

    Thanks

  • Re: Great talk

    by Johannes Jensen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    A concurrent gc runs at the same time as your program. A parallel gc runs on multiple threads. B) in this case would be a gc that runs on multiple threads (its parallel) but is still Stop The World (not concurrent as your program isnt running at the same time as the gc).

  • Re: Great talk

    by Gil Tene,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    First of all, thanks for the compliment :).

    To answer question #1 (and as Johannes also notes): A parallel collector that is not concurrent is simply a collector that uses multiple (parallel) threads to do it's job. but does so with the application in a stop-the-world state (hence non-cincurrent). The most commonly used collector in the Java world is such a parallel-but-not-concurrent collector: The default collector in the Oracle HotSpot JVM (ParallelGC, as in the default is +XX:+UseParallelGC) stops the application for the entire duration of any GC operation (newgen, olden), but uses multiple threads to make that operation take less time then if it had been single-threaded. In practical terms as of 2011, there are few non-parallel collectors around. Non-concurrent is a whole different story...

    For Question (2): [10G to 100G, aren't there limits?]: In the x86 world, on 64 bit servers and OSs (there are no more 32 bit servers being shipped, really), the limitation on the size of a single process's memory is pretty large. E.g. 128TB on Linux, and ~8TB on Windows, so there are no architectural limits here. Practical physical server size is more of a limit, but there too [as I note in the slides], at the current time, a ~100GB x86 server costs less than $5K, a 1TB server is less than $50K (and the prices are fairly linear in between). A 100GB+ heap JVM is a very practical (and non-expensive) thing therefore, except for the annoying issue of the multi-minute GC pause it would come with using most current JVMs.

    This last point is what the Application Memory Wall part of the talk is about (about 1:07hr+ in), and also the reason our newly announced Zing 5 JVM is seeing such great traction - we need to eliminate the link between application scale and responsiveness, and Zing does this using C4 (the Continually Concurrent Compacting Collector).

  • Re: Great talk

    by Jude Paul,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks for the replies Gill and Johannes. Makes sense now.

  • Re: Great talk

    by Marge Galapon,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Great presentation and I have learned a lot.

    Just would like to clarify on the note that was given "Doubling the empty memory, halfs the work of GC"

    From my understanding of this, is, if I have 1GB of free Memory, setting it to 2GB, would reduce the work of GC about 50%? If so, will this not increase CPU instead? Since the GC needs to go all the way to the end of the memory to completely do the work? Base from experience, this actually triggered performance problem.

    Please advise. Thank you in advance.

    Cheers.

  • Re: Slides download

    by Kha Nguyen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I can't download slide

  • Re: Slides download

    by 周 晶,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    yes, I can NOT download the slide too :-(, can anyone help us? thanks!

  • Re: Slides download

    by 周 晶,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    and the error is "AccessDeniedAccess denied"

  • Slides download still broken

    by Fabien Rica,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I'd really appreciate if I could download the slides, can someone fix it?
    Thanks in advance.

    Great talk apart from that issue :)

  • Expired

    by Sijar Ahmed,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Slide download has expired !

  • Great talk

    by Konstantin Milyutin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thank you for such a great talk!

    The only thing that I found counter-intuitive is that first you told that doubling the memory will make a GS more efficient, but at the end you say about the memory wall and that GC prevents us from moving to 40GB. But I guess you meant more memory make a good GC more efficient.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT