←back to thread

Fil's Unbelievable Garbage Collector

(fil-c.org)
597 points pizlonator | 1 comments | 05 Sep 25 00:55 UTC | HN request time: 0s | source
Show context
gleenn ◴[05 Sep 25 04:20 UTC] No.45134958[source]▶
> The only "pause" threads experience is the callback executed in response to the soft handshake, which does work bounded by that thread's stack height.

So this is probably not great for functional/deeply-recursive code I guess?

replies(1): >>45134968 #
pizlonator ◴[05 Sep 25 04:22 UTC] No.45134968[source]▶
Meh.

The stack scan is really fast. There's not a lot of logic in there. If you max out the stack height limit (megabytes of stack?) then maybe that means milliseconds of work to scan that stack. That's still not bad.

replies(1): >>45134985 #
adastra22 ◴[05 Sep 25 04:28 UTC] No.45134985[source]▶
That's a very long time. Milliseconds of work is an entire frame update-render cycle in a modern game.
replies(3): >>45135001 #>>45135013 #>>45135161 #
munificent ◴[05 Sep 25 04:38 UTC] No.45135013[source]▶
Games don't tend to have very deep callstacks. And if a game cared about performance also wanted to use GC, it would probably try to run the GC at the end of a frame when there is little on the stack.
replies(2): >>45135039 #>>45135228 #
1. pizlonator ◴[05 Sep 25 04:43 UTC] No.45135039[source]▶
Yeah UE GC safepoints at end of tick where there is no stack. That’s a common trick in systems that have both GC and ticking.

To be fair, FUGC doesn’t currently let you do that. The GC runs in a separate thread and soft handshakes at various points, which cause your game thread to react at poll checks and exits that might not be at end of tick.

But I could add a feature that lets you to force handshake responses to be at end of tick! That sounds like a good idea