Understanding Java Garbage Collection and What You Can Do about It
Recorded at:
- Share
-
- |
Read later
My Reading List
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.
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.
Related Sponsor
AppDynamics is the next-generation application performance management solution that simplifies the management of complex, business-critical apps.
So what can you do about it?
by
Joe Adams
Re: So what can you do about it?
by
Barry Kelly
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
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
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
Re: Great talk
by
Gil Tene
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
Marge Galapon
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.
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think