4 ms·
> until it does How exactly? > grinds to a halt for several seconds What? Stop-the-world in the realtime collectors is always for a set duration, only to s
by sklogic 10y ago
> until it does
How exactly?
> grinds to a halt for several seconds
What? Stop-the-world in the realtime collectors is always for a set duration, only to scan the registers and tops of the stacks (if there are any stacks at all, stackless implementations have even a better latency).
- jules 10y ago> How exactly? Heap fills up, you need a full collection. During that collection your program is running and allocating, but runs out of space, so it grinds to a halt. Look, there is a reason why Rust is a thing, why realtime collectors are only used in niche cases, why there are people whose sole job is to fix GC issues, why there are people programming in Java/C# very carefully to ensure that a full heap collection never happens, etc. GC isn't a magic bullet.
- sklogic 10y ago> During that collection your program is running and allocating, but runs out of space, so it grinds to a halt. It's a marginal case that should never happen, just like the case of running out of memory altogether. And RC will behave even worse in such a case. Also, all three parts are running concurrently - marker, sweeper and mutator. Sweeper is constantly supplying the mutator with the new free cells from the current epoch, so you don't need to wait for another epoch to start getting new free cells.
- jules 10y agoIt's not about running out of memory altogether, it's about the heap filling up with dead objects while the GC doesn't yet know that they are dead. Of course things are great when they are great and the GC can keep up with the mutator. Yet failure does happen whether or not you think it should happen, hence all the efforts that I mentioned that are trying to fix the issues.