Proposal: Scoped Memory and Arena-Based Lifetime Management

[NuminaOneiron]

Motivation

The .NET runtime today relies on a generational garbage collector (GC). While GC is convenient, it introduces:

• Unpredictable pauses (stop-the-world collections).
• Memory overhead (metadata, write barriers).
• Non-deterministic cleanup (finalizers, disposables).

For high-performance, real-time, or embedded workloads, developers need predictable, deterministic memory management. This proposal introduces scoped arenas as a first-class memory model in C#, enabling applications to run with minimal GC pressure or even disable the GC entirely.

Language & Runtime Features

1. Scoped Blocks

scoped
{
    var list = new List<int>();
    var person = new Person("Ada");
    var buffer = new byte[1024];
}
// Arena freed here

Rules:

• Compiler inserts arena creation/disposal.
• All allocations inside block go into arena.
• References to arena objects cannot escape the block.

2. Scoped Methods

public scoped void ProcessData()
{
    var buffer = new byte[1024];
    var obj = new Person("Ada");
}
// Arena freed at method exit

Rules:

• Method-level arena created at entry.
• Return type cannot include arena objects.
• Parameters cannot accept arena objects unless marked.

3. Scoped Classes

public scoped class RequestHandler
{
    public void Handle()
    {
        var cache = new Dictionary<string, string>();
        var data = new byte[4096];
    }
}
// Arena freed when RequestHandler is disposed

Rules:

• Each instance owns its own arena.
• Fields and methods allocate into that arena.
• References to arena objects cannot escape the class’s lifetime.
• Inheritance restricted to other classes.

4. Allocation-Site Scoping

Allocation‑site scoping allows developers to force an object into the current arena at the point of allocation, even if the type itself was not designed with scoped in mind.

scoped var client = new HttpClient(); // allocated in arena

Rules:

• Works with external libraries not marked scoped.
• Disallowed if type has a finalizer (unless [ScopedAllowed]).
• If type implements IDisposable , compiler requires explicit Dispose() or auto-dispose at arena teardown.

5. Arena Flattening

public scoped void HandleRequest()
{
    var buffer = new byte[1024];
    scoped var handler = new RequestHandler();
    handler.Process();
}
// Compiler merges arenas into one

Rules:

• Nested arenas can be merged if lifetimes are fully contained.
• If nested arena object escapes, flattening is disallowed.
• Compiler decides flattening automatically.

6. Opt-In Model

Scoped memory must be explicitly enabled in project settings:

<PropertyGroup>
  <AllowScoped>true</AllowScoped>
</PropertyGroup>

Rules:

• Without this flag, features are disallowed.
• Ensures developers make an intentional choice, acknowledging trade-offs.

7. GC-Free Mode

If the entire codebase uses scoped lifetimes, the GC can be disabled:

<PropertyGroup>
  <DisableGC>true</DisableGC>
</PropertyGroup>

Rules:

• All allocations must be scoped.
• Any un-scoped allocation → compile-time error.
• Runtime disables GC subsystem entirely.

8. Allocator Strategies

Arenas require backing allocators. The runtime/compiler chooses the best per platform:

• malloc/free → portable, default on POSIX.
• VirtualAlloc→ efficient for large chunks on Windows.
• Custom allocators (mimalloc, jemalloc) → optimized for performance.
• Hybrid strategy → small arenas via malloc, large via OS APIs.

Rules:

• Default allocator chosen per platform.
• If custom allocator unavailable, compiler emits error.

Compiler & Runtime Responsibilities

• Insert arena creation/disposal automatically.
• Perform escape analysis to prevent leaks.
• Enforce interop rules (scoped objects can reference GC objects, but not vice versa).
• Handle async/await by extending arena lifetime across suspensions.
• Provide tooling support (debuggers/profilers visualize arenas).

Conclusion

Scoped arenas in .NET would be a paradigm shift, offering developers the choice between convenience and raw performance, with compiler-enforced safety and platform-optimized allocators.

[Clockwork-Muse]

Non-deterministic cleanup (finalizers, disposables).

While finalizers are non-deterministic, there're also rare.
Far more common are disposables, which are actually deterministic due to the using statement/block (in the sense of unmanaged resources at least - after that they're normal classes that get GC'd as usual).

Scoped Blocks

Net 10 improves on object stack allocation, which provides at least a partial instance of this (and potentially cheaper for some usage patterns).

• References to arena objects cannot escape the block.

What does this mean? Just that it can't be returned? Or does it also prevent passing a value as a parameter to another method? The former is expected, the latter makes it much less useful.

Note that C# doesn't currently have a full lifetime tracking system as would be required for even some of the earlier portions of this proposal. This is an enormous engineering effort.

[NuminaOneiron]

Disposables clean up resources deterministically, but the objects themselves still depend on the garbage collector. Scoped arenas handle both: they dispose resources and free object memory immediately.

When we say, “references cannot escape the block,” we mean that arena-allocated objects can be passed to methods but not returned or stored beyond their scope, preventing leaks while keeping them usable.

Unlike stack allocation, which is fast but size-limited, arenas support larger heap objects with deterministic cleanup. Though escape analysis in .NET is currently method-bound, it could evolve to cover entire classes for broader arena support.

It would be great if the .NET team moved further towards object lifetime tracking, similar to Rust’s approach.

[Clockwork-Muse]

When we say, “references cannot escape the block,” we mean that arena-allocated objects can be passed to methods but not returned or stored beyond their scope, preventing leaks while keeping them usable.

This is both requires really complicated analysis (that is easy to break), and any attempt at this would expose internal method implementation details, where updating a library/dependency could cause calling code to fail to compile (or potentially worse, compile but fail at runtime).

Probably, the requirement would have to be that scoped blocks can only call scoped methods.

It would be great if the .NET team moved further towards object lifetime tracking, similar to Rust’s approach.

This would be an entirely new language, or at least involve a similar engineering effort.

[NuminaOneiron]

I agree — this would be difficult to implement, but it’s just an idea for now. Like the unsafe keyword gives developers low-level control when they need it, enhancing the existing scoped keyword could offer opt-in lifetime management without changing the language.

Scoped arenas would be a safer and more performant alternative to GC.TryStartNoGCRegion, which suppresses garbage collection temporarily but requires a manual GC.EndNoGCRegion to exit. Arenas could offer deterministic cleanup without GC involvement, enforced by the compiler through escape analysis.

[huoyaoyuan]

This is impossible to implement at C# level at all, as well as other high-level languages.

With binary distribution used instead of source distribution, the C# compiler has no view of any callee method. This makes escape analysis being totally broken at method boundary. Adding escape model to public API from another project is also impractical. There have been various discussions around this.

Instead, we are doing escape analysis in JIT, which has whole view of inlined functions, which is most likely to be benefit from this.

[NuminaOneiron]

Correct me if I’m wrong, but the most practical way to support scoped blocks would be through JIT-based escape analysis, since the JIT has full visibility into inlined methods. If scoped blocks were restricted to calling only scoped methods, the JIT could verify that no references escape, without needing cross-assembly escape models or compile-time enforcement.

[huoyaoyuan]

If scoped blocks were restricted to calling only scoped methods

This is totally impractical at all. Most of the BCL won't meet the requirement, and strong no-escape without lifetime management can't do anything meaningful.

[Clockwork-Muse]

ie, you'd have to add the marker to most/all of the BCL first, or figure out a way to mark them that way via JIT, but most of them return some object, so that throws most of that out the window. And for simpler/smaller objects, the efforts with stack allocation yield better results. Additionally, while it's not arena-based, the GC makes a pretty good effort with small short-lived objects.

Note too that at scale, it's often better to arena allocate for multiple homogenous objects at a time, which is difficult for the runtime to understand do (because it's a domain-specific function).

The fundamental problem, though, is lifetime tracking, and C# (and most other languages) just weren't built or architected with this in mind.

[NuminaOneiron]

Totally agree — lifetime tracking is tough. But what if we focused on unmanaged objects only, since they aren’t tracked by the GC, similar to how Marshal.AllocHGlobal works? With JIT-based escape analysis, scoped arenas could safely manage cleanup, especially for bulk allocations, without relying on the GC or complex annotations.

[huoyaoyuan]

There's no "unmanaged object" integrated with language or JIT.
The Gen0 GC heap is quite similar to arena if the survival rate is low.