GC Isolates

[zigzag312]

Problem

Modern C# makes it possible to write high-performance, low-latency code. This requires pre-allocating as much as possible during initialization and then making zero allocations on the heap by using techniques like object pooling, stackalloc, Span<T>, ref structs, etc, to avoid triggering the GC.

The problem is that when carefully written zero-allocation code with low-latency requirements needs to be a part of a larger application, the no-allocation constraint propagates to the entire managed process. Zero-allocation techniques are feasible in individual components, but they become cost-prohibitive at application scale because allocations must be avoided even in modules that aren’t latency-sensitive.

Proposal

Add an ability to create GC-isolated threads that run on an isolated managed heap with its own GC, so GC pauses in the rest of the process don’t affect latency-sensitive work in the isolated thread. Any threads spawned from isolated thread inherit the same isolated heap and GC.

Like Dart isolates, C# GC isolates would use separate heaps with no shared object references, but here the goal is isolating GC pauses for low-latency threads in the same process, ideally with zero-copy ownership transfer between isolates.

Benefits

• Latency: allocations in the “main” app can’t trigger GC STW pauses in the isolate.
• Same-process: keep everything in one process (no IPC tax, easier to write), still get isolation.
• Same-language: keep it all in C#, no need for interop with an unmanaged language.
• Less restrictive: you don’t have to enforce a global no-allocation rule across the entire application.

Practical example

OwnAudioSharp audio framework had to switch to C++, even though it was initially developed as a fully managed C# version that didn’t allocate and performed well. Because currently, any application using a managed audio engine also has to avoid allocations across the entire application to prevent GC pauses from affecting the audio thread.

Summary

This proposal would enable us to put a latency-sensitive component into a GC isolate, insulating it from STW collections happening elsewhere in the app.

Would something like this be technically feasible?

[huoyaoyuan]

A NativeAOT module will have its own GC heap and isolated object references. It only pauses threads known to the module.

• Same-process: keep everything in one process (no IPC tax, easier to write), still get isolation.
• Same-language: keep it all in C#, no need for interop with an unmanaged language.

This is not possible. A foreign GC heap is effectively a foreign native module. It can only be interact with (in-process) interop.
Since the standalone module shouldn't be invoked on the same thread to avoid making it known by other heap, cross-thread IPC must be used.

[zigzag312]

I had thought Dart can do it, but after taking a closer look at how Dart can pass objects from one isolate to another without copying, I've learned it can only do so between isolates in the same isolate group, and all isolates in a group share the same heap.

So, one of my key assumptions is wrong. Is there no technique that would (with tight restrictions) allow passing of objects between isolated GCs without copying?

Maybe something like a shared Pinned Object Heap used by otherwise independent GCs under an isolated-ownership model, where each pinned object has exactly one owning GC at any time and is reachable only from its owner? Could the GCs transfer ownership using move semantics here?

[huoyaoyuan]

This is way too niche and unlikely to work well. GC takes ownership by segments. It doesn't really manage individual objects.
GCHandle would be the correct way to access objects from different heaps, with manual reference tracking.

[zigzag312]

Thank you for explaining the issues with this idea!

NativeAOT module solution does look useful, although a bit less ergonomic. Is there anything that makes interop with a NativeAOT module more straightforward than regular C FFI?

[huoyaoyuan]

There's no built-in mechanism. Using source-generated COM can provide idiomatic OOP interface, but the overhead can become complex.

And also, it needs to be careful to avoid sharing threads between runtimes. Using a dedicated thread for the bridge may be helpful.

[zigzag312]

Thank you for the useful tips!