GarabgeCollection in Gaming

Shared Code
#1

You guys may have not noticed get JUly issue of Java Develoeprs Hournal and read the article at page 39, Garabage Collection Pauses…

The code is also useable in most Java Games…:slight_smile:

The gener cocnept of the article is to setup a patern of garbage collection that gets rid of pauses when apps run for long periods of tiem and other gc hicups you may have noticed…

#2

It will be a couple of days before I can get to the bookstore so cut to the chase and tell us about it man ;D

#3

Well ShareMe seems to have fallen off the planet so I will describe the gist of it.

  • Make sure you don’t have objects sitting around in collections
  • Make sure you set references to null
  • Do manual garbage collections at point when you know you just allocated a bunch of temporary memory (loading files, images, etc)
  • (more useful), build a system that performs regular garbage collection sweeps. This is obvious, but not generally used or advised by Sun. It works well (I’ve actually tested it) because you are collecting at a regular interval that is tunable for your application in a deterministic manner - and it means that when the collection happens, there isn’t as much stuff to collect because you’ve gone out of your way to keep heap trash to a minimum

So in general - its not something that you shouldn’t already know as a Java programmer, its not until you actually use it under load that you really appreciate it. Its the difference between your large application running and being a stuttering mess :slight_smile:

#4

What I found interesting is how the periodic forced collections go completely against the advice of Sun which has always stated (with hotspot at least) that you should rarely, if ever, call System.gc()

It doesn’t seem like something you should be calling (except after initialisation steps etc. like you listed above) for the most part either. It may work… but I don’t have to like it :slight_smile:

Setting references to null explicitly makes sense, but is also a bit ugly… you don’t want null object handles hanging around in general. If it wasn’t a source formatting nightmare, I would try to do the same sort of thing by introducing new scopes for variables that you only need for a short while, eg:


void blah()
{
   // do some clever stuff
   {
          Set stuff = new HashSet(); // need a set for something
          // do more wonderfully clever things with stuff
   }
   // keep going, but 'stuff' is now out of scope
   // so it can be collected AND I can't reference it.
}
#5

Hi there,

if manual gcs do work why aren’t they used or advised by Sun?
???
Thanks 8)

#6

Why no objects sitting around in collections? Eats up free memory causing the GC to scrounge around? Goes against what a lot of people always thought, keep references to dead objects until it’s “safe” to have them collected. Although that view always struck me as based on assumption with little evidence to back up it works. I think a better approach overall is to just rework sections of your program that generate a lot of temporary objects.

I read an article on IBM’s site (which for the life of me I can’t find anymore) that talked about setting the minimum percentage of free memory before the GC kicks in to quite high, and increase the size of the heap while you’re at it (both command line options to the jvm) and you essentially render the gc immobilized unless the situation become really dire. I tested it a tad and it seemed to work, but I’ve never had any crucial situation where I could see if it really helps or not.

But despite all of that, is gc-ing really an issue these days? I hardly, if ever, notice any jerks or slowdowns from the gc in my programs.

#7

I think modern GC are very good in finding out when to start cleaning everything. The new GC’s are so good, that I never have seen any problems in my apps. Btw: I have some very memory comsuming apps that use up to 1 gig of ram and the gc was ABSOLUTLY no problem. Sometimes it’s even bad to call it on your own. I have speeded up the code of a coworker just with removing the GC calls. But try for your self :slight_smile:

#8

That’s what I would have said, but this report was done with a modern VM. They concluded that a periodic call to System.gc() improved the GC pause times. I guess the idea was that it had less to do each time because it happened more frequently.
I figured the pause time would be relative to the size of the heap, not just the number of dead objects… but what do I know :stuck_out_tongue: