6 ms·

I always took GC for granted until I started coding in Zig more and had to worry about managing my own memory. One thing that Zig made pretty easy that's been

I always took GC for granted until I started coding in Zig more and had to worry about managing my own memory. One thing that Zig made pretty easy that's been sort of my go-to is using Arena allocations a lot more. It's pretty frequent that for a chunk of code I know I'll be allocating some chunk of memory and working with it, but then once that's finished I won't need it anymore. So just throwing everything into the arena and then freeing the arena afterwards works great, is fast, and is simple. Are there any garbage collectors that enable this sort of thing? I think it might be vaguely like "generations", but I think even those are inferred and kept track of in greater detail to know when to move between the generations. I'm thinking of somehow earmarking a scope to use its own bit of memory and to not worry about collecting within the scope, and then when you leave the scope being able to free it all. I'm sure there's more complexities that I'm missing. It's just that dealing with memory manually really makes you realize that the programmer probably easily knows expected lifetimes better than can be inferred. The only GC's I've used have been all "don't worry about memory we'll figure out everything". But maybe you could provide hints or something.

mirekrusin 5y ago
Sounds more like ownership annotation than generations. Generations basically takes advantage of the fact that recently allocated memory is much more likely to be deallocated sooner - ie. it's run time/age based. What you're describing with arena is more like ownership where siblings can't outlive ancestors - ie. deallocate when parent/root (arena container) is deallocated.
verdagon 5y ago
Some possibly relevant works: Pony has a separate GC for every actor. I suspect that in practice, these work a lot like arenas; since they're very short lived, I'd imagine that most actors just allocate a lot and then blast it away. [0] Odin (not GC'd) has an implicit "context" that has an allocator, [1] effectively decoupling the allocator from the code. One could use an arena allocator for any function they'd like. Vale (not GC'd) is taking this the context system bit further and makes it memory safe. [2] [0] https://tutorial.ponylang.io/appendices/garbage-collection.html https://tutorial.ponylang.io/appendices/garbage-collection.h... [1] https://odin-lang.org/docs/overview/#allocators https://odin-lang.org/docs/overview/#allocators [2] https://verdagon.dev/blog/zero-cost-refs-regions https://verdagon.dev/blog/zero-cost-refs-regions
jatone 5y ago
the strategy you're mentioning is also known as slab allocation. all GC implementations allow this strategy naturally.

mirekrusin 5y ago

Sounds more like ownership annotation than generations. Generations basically takes advantage of the fact that recently allocated memory is much more likely to be deallocated sooner - ie. it's run time/age based. What you're describing with arena is more like ownership where siblings can't outlive ancestors - ie. deallocate when parent/root (arena container) is deallocated.

verdagon 5y ago

Some possibly relevant works: Pony has a separate GC for every actor. I suspect that in practice, these work a lot like arenas; since they're very short lived, I'd imagine that most actors just allocate a lot and then blast it away. [0] Odin (not GC'd) has an implicit "context" that has an allocator, [1] effectively decoupling the allocator from the code. One could use an arena allocator for any function they'd like. Vale (not GC'd) is taking this the context system bit further and makes it memory safe. [2] [0] https://tutorial.ponylang.io/appendices/garbage-collection.html https://tutorial.ponylang.io/appendices/garbage-collection.h... [1] https://odin-lang.org/docs/overview/#allocators https://odin-lang.org/docs/overview/#allocators [2] https://verdagon.dev/blog/zero-cost-refs-regions https://verdagon.dev/blog/zero-cost-refs-regions

jatone 5y ago

the strategy you're mentioning is also known as slab allocation. all GC implementations allow this strategy naturally.