Blizzard: Goals for multi-process Firefox

It does indeed happen. Let's take as an example the game which introduced more people to Lua than any other application: WoW.

A great difficulty in writing non-trivial WoW addons is understanding how the GC works and optimising your code with that knowledge. Addon authors who assume things like creating a small throwaway table will be cheap end up causing the UI to pause noticeably when those tables eventually get GCd. Memory management actually ends up being a big deal because if you're not careful with how you use it you can cause major performance degradation.

>because even that simple GC is bloody fast (who cares about 1/10s delay here and there?)

A number of demographics, including audio/video editors and - crucially - gamers. 100ms is a *really long time*.

The reason Lua is the de facto choice for game scripting languages is that all other scripting languages are worse; that doesn't mean it's perfect.

> The fact remains that long GC pauses inside Lua while a game object is waiting for a script response

If you were careless enough to write your game logic so that a GC invocation could possibly be triggered while a "game object waits for a script response", sure. And this happens in some games. And it pisses players off when it does.

> who cares about 1/10s delay here and there?

Are you fscking kidding me? We care a massive amount about that! You have a ~16ms budget for any given frame if we want to maintain a smooth 60 FPS. And yes, an occasional glitch for even a single frame that pulls us down to 10 FPS (or even 40 FPS) like you indicate is incredibly noticeable and disruptive. Given how much of that 16ms budget is going to be taken up by useful work by the actual game logic (30% is not uncommon), physics (40% is not uncommon), graphics ("way too damn much"% is not uncommon), etc., we've got a fraction of a millisecond to waste on something like unnecessary memory book-keeping -- at the absolute most -- and that's only assuming the game isn't already pushing the hardware to its limits. If we're on a console or other "out-dated" hardware where many triple-A games have to pull ridiculous tricks just to maintain a smooth 30 FPS, we have absolutely no time to waste at any moment. Spikes in the frame time are significantly worse than anything else; it's way better to the play experience to run at a smooth 30 than it is to run an almost-but-not-quite smooth 60, and some crazy algorithm that might want to semi-randomly scan a large chunk of your memory for garbage is just bad juju.

When something like Lua is used, you'd be surprised at the hoops that are jumped through. It's not uncommon to see Lua states created for every invoked script backed by a custom push/pop scratch memory allocator with the GC flat out disabled so that there is O(1) memory collection time after the script completes. Alternatively, the working set is kept so small via the aforementioned why-even-use-Lua-if-you-do-these tricks that the GC basically has next to no work to do and can be invoked at the end of every frame while waiting for the framebuffer swap. Or the working set's growth is painfully minimized so that the GC only normally needs to be run during level transitions. Or some other trick that is basically comprised of not taking any real advantage of the language to ensure that the GC doesn't screw you.

The same applies to most other off-the-shelf scripting languages used in games, including Scheme (e.g. Naughty Dog), C# (e.g. Unity, and a much much smaller percentage of successful XBLA games than Microsoft wants the general public to believe), Java (e.g. Looking Glass, and Tabula Rasa iirc), Flash (a surprisingly large number of AAA games, actually, via the ScaleForm UI library), Python (e.g. Disney in a few Z-budget games), etc. I'm actually having trouble thinking of any recent major games that I know for sure use Lua, but I'd be surprised if there aren't a few.

Every single one of the major commercial engines implement their own scripting language. Languages that are explicitly designed either to not need GC at all or to only need it in ways that are trivial to handle in bounded time (like reference counting based schemes, where deallocation penalties are paid at the exact moment that an object is unref'd, which makes finding, identifying, and fixing problematic scripts trivial via an engine-integrated script debugger/profiler).

Now, of course there are games that don't follow these rules, and blindly use something like Lua exactly the way you suggest is kosher. You have probably seen these games mentioned in reviews with comments like "choppy framerates" or "wth it runs like crap even on my $5,000 gaming rig" or "best student-project game ever!" :)

(Not to rag on student games. Some of them can be damn impressive. Far more impressive than any FOSS game I've ever seen, for that matter.)

> In practice, GC is problematic when hard realtime response is required

Maybe like applications that have to handle rich multimedia processing on top of a heavy physics simulation and advanced computer graphics that needs to maintain a consistent and unbroken stream of audio/video frames within a small fixed time slice all on relatively cheap, commodity consumer hardware... almost like video games. ;)

Would you be happier if he had said 'unusable *for* applications like games'?