This describes the state of GC like it was 10 years ago (and in a few places incorrectly), at least in Hotspot. Shameless promotion: try out the new G1 (-XX:+UseG1GC), better to use the latest EA JDK7 build.
Is there a better document that explains how the GC works in the latest Java 6 releases (particularly Hotspot)?
I'm doing some GC tuning these days - and there seems to be a lot of false/stale information out there. Something this readable, but accurate, would be helpful.
G1 isn't necessarily the right solution for everyone. In my measurements I found it to be more unpredictable than concurrent mark&sweep. I'm still waiting for it to be improved.
Did you have concurrent collections turned on? It almost always reduces overall throughput of the collector. However in many workloads I expect the G1 to be superior to the current throughput collector....
Could you point out what is incorrect? I'm happy to fix it if you can point out the errors and the source of your information.
G1 will be great, at least in theory, but it's not production ready. Many of our readers need to tune their GC in WebSphere/WebLogic Environments in production environments, they can't use G1 yet.
A fascinating jvm they missed is azul. They claim they can handle 300+GB heaps with pauses < 10 ms by radically changing how gc works. Skim this: http://www.artima.com/lejava/articles/azul_pauseless_gc.html Essentially it continually compacts the heap, but simply doesn't remap all pointers to an object. They then tool the OS vm system / TLB with memory barriers and fix up pointers on access instead of fixing up pointers on relocation/compaction.
Regarding the article, I wonder if it's worthwhile or if there is any research into recycling objects or something like c++ placement new? I guess it doesn't really make sense because in java objects are mostly just a collection of pointers, whereas in C++ objects can themselves be fairly large.
