[JIT] Questions & suggestions regarding escape analysis and heap allocation analyzers

[diegoxd12wee436]

Hi everyone,

I'm a CS student, not a professional developer, so I don't know all the deep technical details of how the compiler works. C# is my favorite language — I find it much easier to read and write than C++ or Rust, which honestly give me a headache.

But I know C# has one disadvantage in performance-critical fields (robotics, real-time systems, high-frequency trading): the Garbage Collector can cause small pauses that C++ doesn't have.

I found out there used to be tools for this:

RoslynClrHeapAllocationAnalyzer: a Microsoft tool that warned about heap allocations (archived in 2022).
HotPathAllocationAnalyzer: a community project that picked up the idea and added an attribute to mark a method as "no allocations allowed here."
My question/idea: would it make sense for Microsoft to officially bring back and maintain a tool like this? Not a change to the language itself — just a build-time analyzer that tells you "hey, this line will allocate memory, are you sure?" for people writing performance-critical C#.

I know C# probably won't fully replace C++ or Rust in every case, but I think small steps like this could help close the gap in scenarios where it matters. Sorry if this has already been discussed somewhere — I'm still learning and happy to be pointed to existing conversations!

[dotnet-policy-service[bot]]

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

[MihuBot]

I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):

• [API Proposal]: Analyzer - check allocation non free code during compilation #70387

[diegoxd12wee436]

I read through #70387, but I think my idea is a bit different.

That issue proposed adding new attributes like [AllocationFree] to the language. My suggestion was just about having a simple build-time analyzer tool (like the old RoslynClrHeapAllocationAnalyzer) that warns you about obvious heap allocations, without changing the language itself.

Since I'm still a student learning how .NET works under the hood, I wanted to ask:

1. Does a simple build-time tool like this make sense, or is it too hard to do accurately because of how the JIT handles memory at runtime (like escape analysis)?
2. Is this something better left to community tools, or is the team exploring anything similar?

I'd love to hear what the team thinks. Thanks!

[huoyaoyuan]

Does a simple build-time tool like this make sense, or is it too hard to do accurately because of how the JIT handles memory at runtime (like escape analysis)?

It's not meaningful to do it before JIT at all, because cross-module calls will always be considered escaping.

Is this something better left to community tools, or is the team exploring anything similar?

The current JIT-based escape analysis is the best thing possible. A potential optimization is to generate per-method analysis result ahead of time, like what ReadyToRun does.

[huoyaoyuan]

I read through #70387, but I think my idea is a bit different.

This is not a good issue to read. Similar requests has been shown as impossible multiple times. It's better to see what's already happening at https://github.com/dotnet/runtime/issues?q=is%3Aissue%20state%3Aopen%20escape%20analysis .

[huoyaoyuan]

Talking more about GC pausing, it can't be eliminated if any heap allocation is happening. It can only be reduced. Aside from reducing GC pressue, it's also important to optimize GC itself (#115627).

[MichalPetryka]

Talking more about GC pausing, it can't be eliminated if any heap allocation is happening. It can only be reduced. Aside from reducing GC pressue, it's also important to optimize GC itself (#115627).

Well AFAIR most of the GC work can happen on background threads, IIRC only compaction and one other thing needed pausing.

[diegoxd12wee436]

@huoyaoyuan and @MichalPetryka Thank you both, this really helped me understand it better!

I didn't know the JIT already had more information available than a separate tool could have before compiling. That explains a lot.

I looked into issue #104936 and saw there's already active work on stack-allocating closures and other cases really cool to see this moving forward. Thanks for taking the time to explain this to me I really appreciate it!

[toupswork]

Good question. Look into GC.TryStartNoGCRegion() and GC.EndNoGCRegion()
However, delaying GC can have negative consequences if used inappropriately, like leading to fragmentation of the heap or causing the pause time to snowball when it ends.