[Off-Topic] John Carmack's point of view on GC and languages like JavaScript

[Ethan]

On Monday, 8 August 2022 at 00:57:52 UTC, Walter Bright wrote:
> I expected Carmack's view to be practical and make perfect 
> sense. I'm pleased to be right!
>
> Anything he has to say about writing code is worth listening 
> too.

Replying to this to emphasise the point.

You know, one of the advantages of Carmack releasing his code is 
that you can see for yourself what his views on GCs are.

https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/z_zone.c

I've spent a lot of time in the Doom source code, and what I've 
linked here is the Zone allocator. No allocation in the code is 
done outside of this, it all goes through zones. Allocating with 
the PU_STATIC zone is the equivalent of a manual malloc, ie you 
need to free it yourself.

Where it gets interesting, though, is the PU_LEVEL and PU_CACHE 
tags. These are garbage collected zones that you don't need to 
free yourself.

The level stuff has persistence exactly as long as it takes to 
reload a level (be it through death/new game/load game/level 
warp/etc). The Z_FreeTags function is used on such a reload to 
deallocate anything with the PU_LEVEL tag. PU_CACHE is a bit more 
fun - if the allocator runs out of memory in the free pool, it'll 
just plain grab something that's marked PU_CACHE. As such, you 
have no guarantee that any PU_CACHE memory is valid after the 
next call to the allocator. This is used for textures, in fact, 
and is how the game both didn't crash out on no memory on 
low-spec 386s back in the day _and_ why that disk loading icon 
showed up so frequently on such a system.

So tl;dr is that there's tactical usage of non-GC _AND_ GC memory 
in Doom. And since it's a C application, there's no concern about 
destructors. Code is structured in such a way that an init path 
will be called before attempting to access GC memory again, and 
the system keeps itself together.

That was also nearly 30 years ago now. And as such, I always 
laugh whenever someone tries to tell me GC has no place in video 
games.

I also shipped a game last year where the GC was a major pain. 
Unreal Engine's GC is a mark and sweep collector, not too 
dissimilar in theory to Rainer's GC (written for Visual D). And 
we had to do things to it to make it not freeze the game for 300+ 
milliseconds. Given that we need to present a new frame every 
16.666666... seconds, that's unacceptable. The solution worked 
(amortize the collect) but it's not really ideal.

I have been meaning to sit down and work on a concurrent GC, but 
LOLNO as if I have the time.

Separately though:

> there is a fork based GC available

Can we stop talking about this please? It's a technological dead 
end, unusable on a large number of computers and mobile devices. 
If that's the best we've got, it's really not good enough.