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.
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).
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.
That's not really a change at the language level. The language doesn't force you to do so, you can simply create an allocator as a global variable and avoid explicitly passing it around, which is basically what happens in every other language. The difference is instead social: everyone is onboard with the idea of explicitly passing allocators around.
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).
[1] https://learn.microsoft.com/en-us/dotnet/api/system.gc.tryst...
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.
Something like Javas -XX:MaxGCPauseMillis?
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).
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.
[1] https://news.ycombinator.com/item?id=44403195
> 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.
What changes does Zig make to "implement" this?
> What changes does Zig make to "implement" this?
The user has to pass the allocator around to all the functions that need to allocate data on the heap. I don't think every language is ready for that.
That's not really a change at the language level. The language doesn't force you to do so, you can simply create an allocator as a global variable and avoid explicitly passing it around, which is basically what happens in every other language. The difference is instead social: everyone is onboard with the idea of explicitly passing allocators around.