Doesn't garbage collection cause distracting hitches?

In my experience the OpenGL drivers will cause more havoc than Java GC.

It depends on how much heap you consume, including textures, levels, models etc.

You can force the GC when you know it will have the least impact.

In comparison to having the FPS you need it's currently a non issue.

Partly because higher FPS require less memory! ;)

There are workarounds for a lot of GC issues, but it means having the Pro version of Unity and using it's profiler to track down and adapt your code to limit the memory allocations and garbage collections.

A simple example is the use of Object pooling for repeating fast use objects, e.g. bullets / missiles / effects.

But this will only reduce the impact of the GC in your game as far as I'm aware there is no way to remove it and some standard calls in Unity allocate memory.

Personally I have found that this approach is helpful but best combined with the optimisation pass on your game.

There are some great threads on the Unity forum for tips and hints that can help you optimise your game and the GC's activity.

Unity is using a very old version of Mono, which does not have a generational/compacting garbage collector. This means that if you allocate anything at all during frame updates, you will gradually start to hitch more and more, fragment your heap, and eventually crash if you leave it running long enough (don't write your game server in unity). This has been a well known issue in Unity for years, but it is not generally true of garbage collectors. They can be performant.

Pooling is definitely necessary, never instantiate or destroy gameobjects during gameplay unless you really really have to (like a new player joins in multiplayer, and even then maybe you shouldn't). Create all your objects at load time and hide what you don't need.

As for the built in functions that allocate memory, just profile and avoid them if possible. Unity GUI is one of the worst offenders, if you use it you will have framerate hitches. NGUI worked ok in my experience, even on mobile with some tweaking. Getting zero allocations per frame is not impossible.

"bp2008" wrote:
For a while now I've been wondering about the effect of the C#/Mono/.NET or Java garbage collectors on VR games. Garbage collectors are well known to cause hitching and stuttering in games.

For Java anyway, it depends a great deal on how much memory management you're doing. For applications that aren't running near the edge of the performance envelope, there's not really an issue. GC happens frequently on background threads that have little. If you're doing something that's consuming and releasing large amounts of memory on every frame, you might have an issue, but then again, if you did that, you might have an issue in a non GC language just as easily.

Even when GC happens in the background there is still a small part of it that needs to lock all threads which will cause your render loop to freeze (that applies to both concurrent and background GCs). So you must be careful not to allocate on every frame at a minimum but beyond that I wouldn't worry too much about it unless you notice hitches.

I think Oracle bought this Swedish company that did a realtime Java JVM for financial services etc. and integrated their code into the official JVM. Somehow they worked around the JVM freezing GC. But really GC is not going to be a problem for Java unless you have horrible memory management. I mean you can just allocate more memory, in a few years we will probably have TB ram... lets focus on FPS instead, that's the silver bullet.