The Annoying Garbage Collector

[Drew Lane]

I just finished writing a fairly simple game in Java.
The one thing that's really annoying about it is that the Garbage collector seems to get called at inopportune times!
Sometimes I'll see a short pause in the middle of the game, which is not good to say the least.
I figure I can try and call System.gc() at a better time in the game cycle so that it won't be so obvious.
Are there other simple tricks I could try?
Would increasing the memory heap help?
Thanks,
Drew

[sander hautvast]

increasing heap won't help you: unreferenced objects pile up until memory full, then GC will take a long time to clean up.
always take jvm into account. There are differences between versions and vendors as to how they deal with gc. Find out how yours works. java 1.4 i believe has a separate thread continuously doing gc
one other strategy would be to have many short lived gc calls. do this by decreasing your initial heap size to what your app approximately needs (for instance by looking at -gc:verbose output). Make your max heap size high enough to avoid outOfMemoryError. maybe your game works better this way, because jvm will try to maintain initial heap size and do gc quite often.

[Mark Herschberg]

You might also wnat to look at RT java (I think it was JSR 1). I have no idea what the status is and how viable it is on the desktop, or with existing code.
--Mark

[Drew Lane]

Unfortunately, I have to use Java 1.1 for this game.

[William Brogden]

Back at the begining of Java applets I wrote part of a baseball game animation applet that followed real major league baseball games. It also had that annoying pause right in the middle of animating a play.
Upon reflection I think my problem was due to creating too many objects that represented animation events. If I was doing it again I would create a pool of events and figure out some way to recycle them.
Calling System.gc() when you are sure the user will be pausing to look at a new screen is also good.
Bill

[Rob Ross]

You might also want to try keeping a reference to your intermediate objects so they actually WON'T be gc'd until you come to a "suitable breakpoint" in your game, like a scene change or a level change, etc. A simple array of Object[] would suffice to hold the references to all your "junk".
Then at your breakpoint, you can set all these references to null and either call gc, or better yet, allocate a huge hunk of mememory (byte[] for example) that you know can't be allocated because there's not enough free memory left..that will *force* the gc to run for sure, after which you know your memory is in a "tidy" state. (Make sure to catch the out-of-memory exception).
I have never tried this but it might be practical to implement if you have enough free working memory available between breakpoints and calls to gc. Ie, if you won't run out of memory before your breakpoint is reached.

[Drew Lane]

These are some really great suggestions.
I think I'm going to try harder at reusing / recycling my objects and beware of the new keyword. Might even try what Rob suggested.
Also, I might be able to just "hide" some of the sprites in the game instead of destroying them and eventually have to create new ones.
I do call the garbage collector when the level changes. I know it's not guaranteed, but so far the garbage collection has been very consistent at the level changes. It's just those in between calls that get to be annoying.
It's also interesting that when you run the game on very fast computers, the garbage collection is hardly noticeable.
Drew
[ May 28, 2003: Message edited by: Drew Lane ]