Garbage Collection and gamedev - tl; dr Yes we want it, so let's solve it

[Ethan]

There's many nuanced points to consider here, so given that GC 
came up on the live Q&A and I got in to a bit of a chat there I 
figured copy/pasting that log and getting in to a (real, 
stop-saying-gamedev-doesn't-want-this) longer form discussion 
about the exact kind of GC we want in game development.

There's a few people in the community here that are involved in 
console game dev, and they would know the kind of characteristics 
we require. Similarly, many of the lower level programmers that 
work with GPUs and the like are well aware that garbage 
collection is not good enough for releasing resources outside of 
the main system environment and would know the kind of control we 
require over deallocation and release paths.

The short form of my view is that we are actively using GC in 
game dev at all levels. The largest commercial AAA engine has 
been garbage collecting since the 90s (and go deeper, the 
original Doom garbage collected). But as we scale up to massively 
parallel execution across all forms of programming, the 
monolithic program-halting mark and sweep GC that comes with D is 
not good enough.

I've not yet sat down to do the full research in to the subject 
that it demands, but I have ideas on what I want to look at. 
Conversation copied to below:


TheRealGooberMan
​I want to write a task-based GC, that will handle 
destruction/deallocation as a task when the last reference to a 
section of memory is unacquired

FeepingCreature
​is freeing memory that costly in D?

TheRealGooberMan
​The advantage of a collector is that it's a batch process

TheRealGooberMan
​And computers LOVE batch processes

TheRealGooberMan
​But in gamedev, we need a bit more immediate control at times

FeepingCreature
​no I mean, it just feels like you're optimizing the fastest part 
of the process

FeepingCreature
​ya'll are really sensitive to question marks ending a line 🙂

TheRealGooberMan
​The collector blocks the program currently. That's bad for 
gamedev

TheRealGooberMan
​And yes, we do have Unreal Engine as the most direct example 
that does exactly this

TheRealGooberMan
​Anyone saying "gamedev doesn't GC" isn't paying attention

TheRealGooberMan
​We just want a better solution

FeepingCreature
​the collector blocks the program, but it blocks for scanning, 
and task-based doesn't speed that up, right?

TheRealGooberMan
​No, it's not about speeding it up at that point. It's about not 
blocking anything else from running

FeepingCreature
​right but mark phase has to block inherently, unless you get 
really clever with your design or get hardware support

TheRealGooberMan
​This is an extra advantage of the pointer acquire/unacquire 
runtime hooks that I want. It's a bit more code, but it also 
negates the need to do any kind of sweep

TheRealGooberMan
​And it is something that should be opt-in, yeah. If your GC 
doesn't define the hooks, then the code gen shouldn't try to 
insert them

TheRealGooberMan
​Pay as you go functionality!

FeepingCreature
​I don't know the background of that, but yeah, I don't know how 
the relative cost of mark and sweep is, if sweep is using a lot 
of the fraction than speed it up by all means

Lawrence Aberba
​I love GC 🐱‍🏍

FeepingCreature
​😆