Interesting, but possibly outdated by now. E.g. they compare against a seven-year-old version of ZGC. Back then, ZGC was not only not generational, but did some scanning during a stop-the-world pause (e.g. of stacks, but not only stacks). These days, even the objects directly on the stack aren't scanned at all during a STW (a pause is only used as an efficient thread synchronization mechanism; no GC work, including the scanning of any object is done in a STW).
The thing I really want is a garbage collector where you can specify a timeout before it stops running. Let it stop the world, but resume the world after 10ms have passed or whatever.
They can't really provide that guarantee. It's possible for lower allocation rates but what happens when 10ms is not enough time to keep up with all of the new allocations? At some point it'll need to stop the world because it's not able to do a complete cycle.
I like the way .NET does it where you can define regions to have the GC avoid running in [1]. You just need to declare how much memory the region should be able to allocate and it wouldn't run the GC unless it is exceeded. This is great for things like games where it's best to let the GC run while the GPU is rendering/presenting (note: not supported in Unity because they use Mono).
During STW GC has to walk all the heap. Checking 50% of live objects tell you nothing about possibility of using memory at address X. Only after checking all objects you know that X is not occupied.
According to [1], arena allocators provide low-latency high-troughput garbage collection riding on top of "practically unlimited" virtual memory implementations of 64-bit machines.
However, it requires changes in the language level, so no wonder so few languages like Zig implement it.
> According to [1], arena allocators provide low-latency high-troughput garbage collection
No, arenas don't really provide garbage collection, they are just a way to organizer your data in such a way that you can more easily collect the garbage later on, but you still need to do that yourself (e.g. decide when to free the whole arena). That article then goes on to show a bunch of what are basically small specialized allocators. It doesn't really solve the problem, it just moves it.
> However, it requires changes in the language level, so no wonder so few languages like Zig implement it.
I like the way .NET does it where you can define regions to have the GC avoid running in [1]. You just need to declare how much memory the region should be able to allocate and it wouldn't run the GC unless it is exceeded. This is great for things like games where it's best to let the GC run while the GPU is rendering/presenting (note: not supported in Unity because they use Mono).
[1] https://learn.microsoft.com/en-us/dotnet/api/system.gc.tryst...
However, it requires changes in the language level, so no wonder so few languages like Zig implement it.
[1] https://news.ycombinator.com/item?id=44403195
No, arenas don't really provide garbage collection, they are just a way to organizer your data in such a way that you can more easily collect the garbage later on, but you still need to do that yourself (e.g. decide when to free the whole arena). That article then goes on to show a bunch of what are basically small specialized allocators. It doesn't really solve the problem, it just moves it.
> However, it requires changes in the language level, so no wonder so few languages like Zig implement it.
What changes does Zig make to "implement" this?