<snip>
If I need something pooled, I don't do it as part of the interface to the object, I have the class that's using the object do it's own pooling. That way pooling is an individual choice of the user. It also keeps the code clean by not exposing pooling to the outside user. <snip>
SciVis applications, at least the ones I'm involved with, do something similar to that if an opportunity exists. A descriptive name for this could be local-temporary-object-recycling. Local because the pooling impact is restricted to a class or a bunch of very related classes comprising a single visual component, and temporary because the pool is destroyed if the visual component is destroyed. The latter is typically done because anticipating what goofy thing the user might request next is quite hard in a scivis application. With this approach, because the parameters defining the visual component are clearly known, it is easier to tune the local pool size if you want to. This kind of local object "recyling", IMO, may be seen to be a more restricted version of the generic "Object Pooling".
And again from a scivis perspective, gc pauses before a visual component is created or after it is destroyed is permissible, but certainly not during the course of its animation. But I can understand the difference here with respect to games - you can pre-allocate only so many number of objects. And when do you choose to create/destroy objects on the fly is a much more difficult problem.
Overall, as I might have already expressed it many moons ago, (1) I usually code with a mistrust for the gc; (2) gc fine tuning is futile because of the very cross-platform nature of my application and because I have absolutely no clue about even the Xmx memory size that a user might choose to specify. Having said that, however, with respect to games, if you know your (major) target platform, then using something like jvmstat may be a worthwhile excercise.
