Ultra low-latency GC

[miloszkukla]

In Singularity OS'es paper https://www.microsoft.com/en-us/research/wp-content/uploads/2005/10/tr-2005-135.pdf there is an information about garbage collectors available and the one that is used for system code:

Singularity’s run-time systems currently support five types of collectors—generational semi-space, generational sliding compacting, an adaptive combination of the previous two collectors, mark-sweep, and concurrent mark-sweep. We currently use the latter for system code, as it has very short pause times during collection. With this collector, each thread has a segregated free list, which eliminates thread synchronization in the normal case. A garbage collection is triggered at an allocation threshold and executes in an independent collection thread that marks reachable objects. During a collection, the collector stops each thread to scan its stack, which introduces a pause time of less than 100 microseconds for typical stacks.

Would that be possible/make sense to have such a low-latency GC in .NET for scenarios like image/audio rendering?
I guess a possibility to skip a particular thread when scanning would solve the latency problem definitely but there is no public way to manually delete managed objects and there are good reasons not to introduce such way?

cc @Maoni0

[ghost]

Tagging subscribers to this area: @dotnet/gc See info in area-owners.md if you want to be subscribed.

Issue Details

---

In Singularity OS'es paper https://www.microsoft.com/en-us/research/wp-content/uploads/2005/10/tr-2005-135.pdf there is an information about garbage collectors available and the one that is used for system code: > Singularity’s run-time systems currently support five types of collectors—generational > semi-space, generational sliding compacting, an adaptive combination of the previous two > collectors, mark-sweep, and concurrent mark-sweep. We currently use the latter for system code, > as it has very short pause times during collection. With this collector, each thread has a > segregated free list, which eliminates thread synchronization in the normal case. A garbage > collection is triggered at an allocation threshold and executes in an independent collection thread > that marks reachable objects. During a collection, the collector stops each thread to scan its stack, > which introduces **a pause time of less than 100 microseconds** for typical stacks. Would that be possible/make sense to have such a low-latency GC in .NET for scenarios like image/audio rendering? I guess a possibility to skip particular thread when scanning would solve the latency problem definitely but there is no public way to manually delete managed objects and there are good reasons not to introduce such way? cc @Maoni0

Author:	miloszkukla
Assignees:	-
Labels:	`area-GC-coreclr`, `untriaged`
Milestone:	-

[Maoni0]

this is really not about the GC. it's about having a way to guarantee a thread only ever accesses its own portion of the heap that's completely isolated from the rest of heap, so you can do a collection just for that thread. the GC itself mentioned in the paper is a concurrent mark and sweep GC, which we've already had for many years.

could we build such a feature that limits threads to their isolated heap? it could benefit certain scenarios but I doubt this is something that we'd get to consider anytime soon.