Golang: sub-millisecond GC pause on production 18gb heap

I was writing the Java part of a cross-platform game engine once, and I was trying to eliminate all dynamic allocations during the game (front-loading all allocations and then never touching the heap). Did some profiling and determined I'd missed something.

The allocation turned out to be in a call to get the current system timer (in milliseconds, if I recall). I was calling a Java function that returned a Java long int, probably straight from an OS call that returned a 64-bit int, and somewhere in that call it was allocating an Object.

Ripped out the Java library call, replaced it with a JNI call to a two line C function that returned the result of the corresponding OS call. No more dynamic allocations.

It's just part of the philosophy of Java to allocation things everywhere. So it's not only hard to make a GC fast for architectural reasons; the GC also tends to be worked harder by the way Java code tends to be written.

For example Wooga has quite a few games using Erlang, Hallo used C#/Project Orleans, just to cite two examples.

Direct link : https://github.com/golang/proposal/blob/master/design/17503-...

I've written 3D/Game Engines engines in languages with GC based runtimes that run at 1500fps with no GC pauses.

How to do it? Easy... don't create garbage! So yes, it is doable. PITA but doable

Certainly helps if you have a good generational GC.

That said, if you can force a compaction once a frame and it's pretty stable at a millisecond, I guess that's more than fine for a lot of stuff.

The catastrophic problem with GC for games isn't the specific amount of time it takes up, it's that it's a periodic task; it perhaps happens once every few seconds, or even less. Which means that if you're going to have GC in your game, then you're always going to be discarding some percentage of the available CPU time so that you can survive the occasional frame where the GC runs. (or else you're having frame rate hiccups every time it runs)

Nobody in the AAA industry wants to say "Okay, lets only use 90% of the hardware's capabilities, so that those few frames in which the GC is going to run, it won't cause a frame rate hitch"; we instead engage in extraordinary (some might say 'heroic', others might say 'foolhardy') amounts of engineering effort to remove those periodic expenses, so we can move ever-closer to consistent 100% usage of the available hardware capabilities.

Sometimes that means "we're going to build this in a more difficult language which doesn't support GC", sometimes that means "we're going to figure out how to build this in this GC-enabled language without doing anything that would accidentally invoke the GC", and sometimes that means "we're going to figure out how to provide our own GC implementation which operates progressively, only spending a budgeted amount of CPU time per frame".

Personally, I skew toward that first solution. But I'm old-fashioned that way. :)

(caveat: I haven't actually worked on a 'AAA' game in the current console generation, and the majority of my industry experience was during the PS2 era. Stuff might have changed in the last few years, though I imagine that the basic principles still hold.)

60fps is roughly 16ms, for reference.

Audio is different, it's often about round trip latency (eg. from the time the sound is made, to when it is heard back) and has a few additional issues to consider. Eg. there can be phasing issues where one signal cancels out or amplifies another.

This is controlled by varying the buffer sizes, but issues can still arise due to processing latency. If the output buffer falls behind you'll hear pops as the speakers cut out.

A lot of DSP code is written to be lock-free by allocating vars when initializing so no memory allocations actually occur during updates. There are a couple great youtube talks on the subject. (look at the JUCE and CppCon channels)