I\'m looking for arguments as to how best to size the young generation (with respect to the old generation) in an environment where low latency is critical.
My own t
Have you already enabled more relevant GC settings, like selecting a concurrent low-pause collector algorithm?
Broadly, the young, tenured and permanent generations need to be sized to match your application's profile. If you have many short-lived objects but young is too small, lots of objects will become tenured, forcing more frequent major collections of the entire tenured generation. Likewise if young is too large, then tenured is necessarily smaller, and might force frequent major collections of tenured.
Practically speaking, I think you will find that the time spent in minor vs. major collections trades off as you increase the size of the young generation, and is optimal at some point.
Maybe it's helpful to note that in "big" performance-sensitive server applications, I've found it necessary to shrink the young generation, in general. This is because such applications ought to have been profiled already for memory allocation hotspots and optimized, so they're producing few short-lived objects. This in turn means the young generation is hogging too much of the heap.
So I suppose I'd do that optimization first, then look at turning up NewRatio beyond 8, and watching the output given by -verbose:gc to see how GC and Full GC time trades off and where it's optimal.