A proposal to add GC-less, unmanaged memory spaces to C# | Hacker News Reader

A proposal to add GC-less, unmanaged memory spaces to C#

axx83.substack.com

13 pointsaxx8320 comments

You can write an arena allocator referencing a pointer allocated via Marshal.AllocHGlobal and proxying it via Span<T> very easily in literally like 30 lines of code which will achieve whatever you're suggesting there, can also add where T: unmanaged if you don't want the ability to reference things which can be tracked by the GC, this is already possible right now and is fully enforced.

You can add 30 more lines of code to your arena with some PInvoking on windows calling AddVectoredExceptionHandler and VirtualAlloc, which will allow you to allocate whatever amount of memory you'd like without actually committing it, creating a very optimized and easy to use alternative to whatever you're suggesting.

The only problem I see with this approach is lack of standard data structures allocated in native memory. In GC memory you have collections and strings. In native memory you would have to create such data structures yourself. Plus figure out interoperability between the two.

You've hit on the exact problem. The friction of interoperability is the real wall.

Now, imagine if that friction disappeared. Imagine 90% of your codebase is safe, using traditional collections and strings, while only the critical 10% uses high-performance, native data types. What if moving between these two worlds was a natural, compiler-guaranteed feature, not a manual, error-prone task? How amazing would that be?

This vision of seamless coexistence is the core of my proposal. I've detailed it in a new, more focused post and would love for you to take a look.

https://news.ycombinator.com/item?id=45477324

It looks like a process model; isolation between programs with a system for inter-process communication, and running within a single process's memory.

If I understand correctly, instead of writing a c++ application to offload the computation of something, and then build a way of communicating the result between processes, you create a Space, define it as JIT/AOT, managed/unmanaged and execute it and use the built-in communication for transfering data.

It is an interesting approach. The author should check out Unity's Burst compiler. It takes a chunk of C# code, AOT compile it with LLVM and then the main application can invoke it. The concepts are adjacent.

Even something like Burst is, IMO, not really necessary in modern C#/.NET. It does well in benchmarks but they are almost always comparing Burst vs. normal C# in Unity. Problem is C# in Unity is stuck so far in the past that it makes Burst look amazing when it's usually not that much quicker. So if you are using modern .NET you're not restricted to a subset of C# and get good performance. And if you need even better performance there are plenty of new language features to get you there.

I generally agree. However, there are several important optimizations that Roslyn does not yet have. I love the improvements in newer versions of the compiler as much as the next guy, but historically, waiting 20 years on getting basic inlining, hoisting and SIMD accelerations has left many of us with the only option of not relying on C# for performance.

> It looks like a process model; isolation between programs with a system for inter-process communication, and running within a single process's memory.

Which is better handled by existing mature and simpler abstractions from the actor model, like Akka.net, or maybe Orleans.

For sure, but the author also proposed "unmanaged spaces" which would run in-process but with no GC. This seems to be the main goal and everything else is definitely better handled with existing solutions.

Forgive my relative inexperience as a newcomer to C#, but doesn't it already provide things like stackalloc, Span and unsafe for these things?

It does but the GC can still stop-the-world pause threads that aren't touching GC memory. The author's proposed isolation would provide a way to avoid that.

Hi rohansi,

I wanted to reply to you directly. I was truly impressed by your comments. You understood the precise, deep technical problem I was aiming at—the GC's 'stop-the-world' pauses affecting even non-GC threads—even from my admittedly clumsy and brief initial post. Thank you for that.

What I failed to convey properly, however, is that this performance mechanism is just one small consequence of a much larger idea. It's a foundational piece of a complete architectural model I've designed to address the fundamental pains of the current microservice paradigm.

I have now finished a full manifesto that lays out this entire vision. It includes a deep critique of our current ecosystem and presents the philosophy for a new style of programming intended to solve these core issues.

Given the depth of your understanding from that first article, I would be genuinely honored to get your critical feedback on the full proposal. If you're interested, the new post and discussion are here: https://news.ycombinator.com/item?id=45477324

Thanks again for your incredibly insightful comments.

Don't really understand how this proposal connect to microservices, as it solves only one of the myriad of problems that architectual pattern addresses.

Second, why do we need the "spaces" concept for dealing with no GC work? And what does it really solves? Meanwhile, the proposal lacks explanation on how C# behaves on the non managed world, like better syntax for allocation and deallocation, etc. No ownership model would make it a hard sell over Rust.

Hi HeavyStorm,

Thank you for the excellent and critical questions. You've pointed out the biggest flaw in my first article: it failed to properly connect the proposed concepts to the broader "myriad of problems" in the microservice ecosystem.

I have written a new, much more detailed manifesto that is almost entirely dedicated to explaining that connection and the architectural vision. I believe it addresses your first point directly.

But I also want to be transparent with you in particular. You asked about the low-level details—the "how" of C# in a non-managed world, memory management, and how it compares to Rust. You are right to ask for this. That new manifesto is still the philosophical 'why', but I want to assure you that I have already completed a full technical whitepaper that covers the 'how'.

The challenge is that the whitepaper is currently in my native language (Vietnamese), is quite long (around 150k characters), and I am still revising it before I can begin the translation.

So, I would like to propose a path forward. First, I would be grateful if you could read the new manifesto and give me your honest critique there. It lays out the complete architectural argument. https://news.ycombinator.com/item?id=45477324

If, after reading it, you trust the vision a bit more, I hope you'll be patient for a short while longer until I can properly translate the technical whitepaper which addresses your remaining concerns.

Alternatively, if you're curious to see the raw draft now, you can likely find it by searching my username plus the keyword "Viblo". You could then use an LLM for a preview translation, but I must give a strong disclaimer that I cannot promise the quality of an automated translation of an unrevised draft.

Thank you again for the sharp feedback. It's exactly the kind of critique that is needed.

I've learned to embrace the GC. In workstation mode, the latency can be so low that the pauses don't matter.

There are also other implementations of GC for C# with very interesting properties:

https://docs.unity3d.com/6000.2/Documentation/Manual/perform...

Reading this makes me angry.

C# has its own share of warts when it comes to AOT -- it doesn't yet support OpenBSD; it does not yet support all reflection oriented keywords; it requires significant changes to msbuild to work with in a standalone context.

But this article reads like someone with minimal background in software went on a LLM prompted delusion and lacks an understanding of the C# language architecture, associated build system, and philosophy. Additions of keywords like the proposed "overspace" attempting to shoe-horn both inappropriate approaches and ideas are a plague on the community.

Yeah, this doesn't look like something from .NET team.

For me what makes me angry on .NET is the selective support of what lands outside Windows, the way Xamarin went down, and the need to continuously add language features to justify the team size and new release cycles, how will C# look a decade from now with that velocity adding features.

Thank you for your feedback. I apologize if my original article was misleading. I can see how its focus on performance aspects made it seem like just another language feature proposal, which was not my primary intention.

My main goal is to address the architectural complexity of microservices. Based on the feedback, I've written a much more detailed and focused follow-up that concentrates solely on that vision.

The new post and discussion are here: https://news.ycombinator.com/item?id=45477324

If you're willing to give the idea a second chance, I would be grateful for your thoughts on the new version.

I can't tell if this is satire or not. And some parts read like it was written by AI.

Either way, a more fine grained control over the GC is probably preferred over something like this.

The whole post is obviously LLM spam. e.g.

> It is the conductor [emoji] that directs the symphony of independent Spaces.

this pattern is a meme by now.

Hi all, my apologies for the very late reply. I honestly didn't expect this post to get any attention and haven't checked back until now.

I want to clarify that the ideas in this manifesto are entirely my own. As I mentioned in the preface, English is not my native language, so I used AI tools to translate my original text. This is likely why some parts have an "AI-like" feel.

Thank you for the feedback; it's genuinely helpful. The substance of the work is what I truly wanted to share.

Reply on news.ycombinator.com