How many objects are eligible for Garbage collection in Java?

Today, what's the best garbage collection setup for a large server java application?

• With Java7's release coming soon, we're re-evaluating our GC setup. The application serves up to 100k clients that send mostly short-lived requests. However some activity persists long-term. Due to the use of reflection in a few places there is also constant perm-gen object creation and collection. So the heap ends up containing mostly recently created objects due for collection; objects relating to longer lived activities in the old gen; and the perm gen churning away a little. Wondering if G1 is going to work well with this workload. We have it enabled on some test servers, but so far not on the big production boxes. Heap size is 30G+

• Answer:

  For server class applications, where "server" refers to something that sits in a rack, and that you can buy for reasonable $$ in 2012 (e.g. a 96GB, 2 socket, 24vcore server that lists on the Dell web site at ~$4K), and "server application" refers to something that actually uses a respectable fraction of that server, you pretty much need a collector that can actually handle many GBs of live data. And by "handle", I mean run for days on end without thrashing, pausing your application for seconds at a time, eating up all your CPU, or coughing up blood. The various still-think-that-stopping-the-world-is-a-way-to-go collectors that worked well for 1GB or even 10GB computers can't seem to cut it at modern server sizes, for various reasons. Some have to do with the inevitability of compaction (and it's cost at even "small" modern server sizes), and some are simply due to the fact that even a tiny "young generation" that is 2-3% of a server will occasionally see multi-second pauses due to application "phase shifts" (think catalog updates, cache flushes and hydration, and pretty much any other big state changes that affect your  GB of live data in some spike). The only lasting answer for "server applications" will be in collectors that do not stop the world (not even "rarely") to do any operation whose length is tied to your key application metrics: Application metrics like concurrent sessions or clients, or data set size, or transaction rate, etc. (and internal memory management metrics like live set size, heap size, allocation rate, mutation rate, promotion rate, etc.). Right now, I know of only one working server collector that creates this decoupling - The C4 collector in the Linux/x86 Zing JVM. C4 stands for "Continuously Concurrent Compacting Collector", and it uses a brute-force, concurrent Mark/Compact approach for collecting both the old and the new generations (yes, even newgen collections are concurrent). For Zing, compacting 30GB+ heap on a modern commodity server feels like a walk in the park, and the only "currency" it needs to keep things flowing smoothly and efficiently even at multi-GB/sec allocation and mutation rates is empty memory. And yes, I'm biased. C4 is my baby..