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.
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.
So what can you do about it?
Re: So what can you do about it?
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
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.
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?
Re: Great talk
Re: Great talk
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
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.
Slides download still broken
Thanks in advance.
Great talk apart from that issue :)
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.