What are the issues with preallocating objects in Java?

Question

We've spent the last few months tuning our production application so that we experience no full GCs. We now experience young GCs only, with the rate of young GCs dependent on the rate of object allocation.

Our application needs to be as close to "real-time" as possible so now we're trying to reduce the number of young GCs. As the old axiom goes, most of the data we allocate ends up being garbage and discarded at the next young GC. So no need to preallocate for this type of data. However there is a good amount of objects (defined by type) that we know will make it from young GC to old GC.

Would it make sense to preallocate these objects during more ideal times (i.e. at startup) so we'll end up allocating less during our less-than-ideal times? I've read the literature that mentions how object pooling is not recommended with the latest JVMs because allocation is much cheaper. What are the drawbacks to preallocating objects that I know will make it to the old GC?

Answer 1

Reducing the rate of allocation makes GC "pauses" less frequent, but not shorter. For smoother "real-time" operation, you may actually want to increase the number of GC invocations: this is trading more GC-related CPU in order to get shorter pauses. Sun's JVM can be tuned with various options; I suggest trying -XX:NewRatio to make the young generation smaller.

The usual argument against pooling is that you are basically trying to write your own allocator, hoping that you will do a better job at it than the JVM allocator. It is justified in some specific cases where allocation is expensive, e.g. creating Thread instances.

Answer 2

Just a note that there is a realtime jvm available. If your app needs predictable performance then this is a worth looking into.