[ZoFreX]

> e.g. JVM which doesn't really require hacks like that anymore.

Is this the case?

I used to be pretty in-touch with Java, but haven't been keeping up from the release of 7 onwards. I've picked it up again for game development, and 100% of the performance advice I've found is to use object pooling... but nearly all of that advice is years old, and I have no idea if it still holds true for JRE7 or even JRE6.

It did strike me as something the JVM should be doing for me, so if that has been fixed, that news will be greatly welcomed by the Java game dev community.

[pmahoney]

"Public service announcement: Object pooling is now a serious performance loss for all but the most heavyweight of objects, and even then it is tricky to get right without introducing concurrency bottlenecks."

  -- Brian Goetz in 2005

http://www.ibm.com/developerworks/java/library/j-jtp09275/in...

This article was also written when Java 6 was starting to get escape analysis, which can result in stack allocations in some cases.

I recall taking a course in 2008 or so (Java 6). We were doing a genetic simulation of sorts, and the professor recommended using an object pool to speed things up. I implemented one and observed no measurable difference in my code's performance (these were very small objects used over and over again evolving new organisms). I hooked up a profiler and used that to guide me to some areas that could be improved, and a valuable lesson was learned.

[lucian1900]

Especially the newer generational GCs are very good at letting you create and destroy lots of short-lived objects. Object pools may only be useful for long-lived objects, maybe.

[craigching]

For Java 6 and 7 I would say don't do object pooling, this is probably true for 4 and 5 as well. Creating a new object in Java is very inexpensive and it keeps getting improved. The only argument you might be able to make against creating lots of objects is garbage collection, and for that I'd say profile when you have problems and change only then.