Garbage Collection

[grom]

Hey there, I am very impressed by Terasology project. It is awesome to see a voxel engine like this as open source software. I am curious to see how game using Java handles the Garbage Collection issue and so I started looking at the Terasology and it appears to me it can create garbage during the main game loop. For example, org.terasology.math.AABB intersectRectangle method . Or org.terasology.core.world.liquid.LiquidSimulator blockChanged method.

Therefore how does Tersology handle garbage collection? Is it using the default garbage collection settings of the JVM? What impact is garbage collection having on the frame rate / logic loop etc?

 

[Cervator]

Hi grom and welcome!

Immortius would be the best person to answer this

One note: The existing LiquidSimulator is disabled pending a complete rewrite, so at least that one we don't have to worry about

If you're finding spots that can be optimized, help with that would be hugely appreciated!

 

[grom]

Hey Cervator. Yeah I haven't touch java gaming stuff in years. The way I learnt was to never allocate memory in game loops at all. So instead use pre-allocated space (ie. object pools). Or say you using C++ you can also stack allocate. But Java objects are heap allocated (though the JVM can optimise them to stack allocations). Be interesting to see what time is spent and how often in the garbage collection. How well Java has gotten with short lived objects.. see if it actually stack allocates them where it can. I will see about setting up development environment and seeing if I can pitch in.

 

[Immortius]

We've done little to tune garbage collection at this stage, except switch to Java 7 (which has better garbage collection than Java 6). From what I've seen on a modern PC, garbage collection of short lived objects is pretty cheap. The only effect I've seen is spikes in nondeterministic parts of the code, and generally not to the extent that would affect frame rates, although my computer is pretty decent so it might be more of an issue on lower-end machines. And certainly something that needs to be investigated if we move to support Android.

I have had a brief look at allocations (YourKit is great here, and I put an extremely basic allocation track into our built in performance monitor). There are probably just a few major hot spots that could be addressed. As part of the switch to a new math library I was thinking of adding some object pool support, but primarily for use for those hot spots. Need to be careful not to prematurely optimise - we're not feature complete, so need to avoid making things overly complicated even if performance isn't ideal.

Notably our physics library JBullet used a special bytecode injector to put math objects onto the stack, but I ended up removing this as it was causing strange crashes. Performance doesn't appear to have suffered.