Since Roc uses automatic reference counting instead of garbage collection, how does it deal with memory fragmentation? As I understand it, that's something garbage collection does but ARC doesn't.
tracing GC, especially generational, can directly do things about memory fragmentation, whereas memory fragmentation isn't really in scope for reference counting - that all depends on the allocation strategy, which can be adjusted independently of whatever is going on with reference counting
here's an example of an allocator that deals with memory fragmentation: https://youtu.be/c1UBJbfR-H0
since roc puts platforms in charge of all allocations, if a platform author was concerned about memory fragmentation, they could use an allocation strategy like this - with or without reference counting! :grinning:
so I guess all of that is to say "at the language level Roc doesn't do anything about it, but it does give platform authors the ability to do something about it if that's something it makes sense to optimize that platform for"
(defragmenting memory has costs, and for many platforms - such as noninteractive batch scripts - that cost may not be worth it!)
Thanks for the link. I vaguely remember seeing that but it was a while ago. I'll have to rewatch it.
Will each platform author need to implement their own defragmenter (for those who need it) or will there a default implementation people can use? Maybe I'm misremembering the video but I think it did something sneaky with OS pages to defragment memory and that seems like something that might not work on simpler hardware?
I guess the platform could do its own "stop the world" defragmentation as well. I'm not that familiar with what kind of information the platform has access too but if it knows what Roc data is pointers then it could change them and make the memory compact again.
in general, allocation is entirely up to the platform author to implement; the language doesn't get involved at all
that said, code sharing among systems languages is still a thing! It's not like everyone would have to write it themselves; more likely they'd get that allocator from a library someone else wrote, unless they wanted to customize it :big_smile:
I realized some of my confusion was thinking that an allocator couldn't fix fragmentation since it doesn't move around existing memory. But of course, it can prevent fragmentation by allocating memory in a smart way.
yes, one example of that is https://github.com/microsoft/mimalloc
it does list sharding, where it has many lists of allocations of various sizes, and when you allocate something new, it doesn't "randomly" pick a location on the heap, but puts it into one of those lists
Last updated: Jul 05 2025 at 12:14 UTC