Stream: ideas

Topic: GC during async

Richard Feldman (Oct 11 2022 at 01:01):

here's an interesting thing a platform can already do if it wants to:

Richard Feldman (Oct 11 2022 at 01:01):

implement roc_dealloc to push to a list of "TODO: free this memory" pointers

Richard Feldman (Oct 11 2022 at 01:02):

then whenever an I/O function runs, run it as async and then while waiting for it to come back, go through the TODO list and free as many of them as possible - checking after each one if the I/O function finished

Richard Feldman (Oct 11 2022 at 01:03):

that way it's sort of like an incremental garbage collector that only runs while waiting for I/O

Richard Feldman (Oct 11 2022 at 01:04):

(although the reference counting still happens in realtime, of course)

Richard Feldman (Oct 11 2022 at 01:05):

could also do https://www.microsoft.com/en-us/research/video/compacting-the-uncompactable-the-mesh-compacting-memory-allocator/?lang=fr_ca in a similar way, to reduce fragmentation

Ayaz Hafiz (Oct 11 2022 at 01:12):

that’s a really cool idea

Ayaz Hafiz (Oct 11 2022 at 01:13):

i wonder how that would perform compared to concurrent GC in practice. i bet it would probably just as fast, if not faster, when your workloads are IO heavy

Richard Feldman (Oct 11 2022 at 01:21):

hard to say! On the one hand, you're paying for the RC when you're going, and on the other, I'm not sure how much free is costly (e.g. recording the memory in a particular malloc bucket as unused, and possibly returning it to the OS) versus using free a bunch makes malloc more costly later (e.g. figuring out which bucket has free space to put the new memory in)

Richard Feldman (Oct 11 2022 at 01:21):

it would be cool to experiment with

Richard Feldman (Oct 11 2022 at 01:23):

another potentially neat thing it could do would be to mmap a new page or two in the background before it's strictly needed by malloc, so that the next time you do an allocation it doesn't have to wait for the syscall to finish

Richard Feldman (Oct 11 2022 at 01:23):

(only when you're down to 1-2 blank pages remaining, of course)

Ayaz Hafiz (Oct 11 2022 at 01:27):

You could tune a malloc/free with a free list implementation that's better suited for your workload

Ayaz Hafiz (Oct 11 2022 at 01:28):

but a concurrent GC would face the same challenges, with the additional overhead of synchronization. which is what makes me think this could be more promising than that

Ayaz Hafiz (Oct 11 2022 at 01:35):

the results in this paper are pretty interesting: https://www.cs.utexas.edu/users/mckinley/papers/urc-oopsla-2003.pdf. Check out section 5 and 5.2 especially

generational GC with RC for long-lived objects. that could lower the cost of RC (though you couldn't control that in Roc)

Last updated: Jun 16 2026 at 16:19 UTC