10 ms·

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

13 points by axx83 1y ago

asabla 1y ago
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.
- shiomiru 1y ago
  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.
  - axx83 1y ago
    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.
mgh95 1y ago
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.
- pjmlp 1y ago
  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.
  - axx83 1y ago
    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 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.
Genbox 1y ago
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.
- Rohansi 1y ago
  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.
  - Genbox 1y ago
    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.
- guiriduro 1y ago
  > 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.
  - Rohansi 1y ago
HeavyStorm 1y ago
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.
- axx83 1y ago
  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 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.
kaibutsu 1y ago
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.
- kikimora 1y ago
  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.
  - axx83 1y ago
    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 https://news.ycombinator.com/item?id=45477324
bob1029 1y ago
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/performance-incremental-garbage-collection.html#incremental-garbage-collection https://docs.unity3d.com/6000.2/Documentation/Manual/perform...

13 points by axx83 1y ago

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.

shiomiru 1y ago
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.
- axx83 1y ago
  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.

mgh95 1y ago

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.

pjmlp 1y ago
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.
- axx83 1y ago
  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 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.

Genbox 1y ago

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.

Rohansi 1y ago
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.
- Genbox 1y ago
  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.
guiriduro 1y ago
> 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.
- Rohansi 1y ago

HeavyStorm 1y ago

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.

axx83 1y ago
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 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.

kaibutsu 1y ago

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.

kikimora 1y ago
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.
- axx83 1y ago
  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 https://news.ycombinator.com/item?id=45477324

bob1029 1y ago

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/performance-incremental-garbage-collection.html#incremental-garbage-collection https://docs.unity3d.com/6000.2/Documentation/Manual/perform...