It would be better if the GC can be turned off with a switch and just add a delete operator to manually free memory.

Yes and no. Yes, almost all of the standard library collection are allocation heavy and it is still the dominate pattern in C#, so if you want to avoid the GC you need to avoid these and resort to building your own primitives based on Memory/Span. Which sucks.

However, you can use interfaces in a no GC world since you can constrain those interfaces to be structs or ref-structs and the compiler will enforce rules that prevent them from being boxed onto the GC heap.

Also of recent note, the JIT can now automagically convert simple gc-heap allocations into stack allocations if it can trivially prove they don't escape the stack context.

> It would be better if the GC can be turned off with a switch and just add a delete operator to manually free memory.

It is a little know fact that you can actually swap out the GC of the runtime. So you could plug in a null implementation that never collects (at your own peril...)

As for a delete operator, you can just roll your own struct based allocation framework that uses IDisposable to reclaim memory. But then you need to deal with all the traditional bugs like use-after-free and double-free and the like.

For me, I think low-gc is the happy medium. Avoid the heap in 99% of cases but let the GC keep things air tight

How do you do this? Just so I can have another tool in my tool shed. Googling got me to an archived repo on GitHub with a sample GC - which is enough but Wonder if there’s something off the shelf.

In java land, the Epsilon GC (a do nothing GC) enables a pattern that’s handy in perf test jobs in CI pipelines occasionally for some projects (I.e. run with epsilon but constrain max memory for the process - ci builds will fail if memory usage increases)

I am not aware of any production grade replacement GCs for .NET out there currently

https://github.com/kkokosa/UpsilonGC

I forgot that there is built in support for this model using the MemoryManager<T> class [0]. A memory manager is an abstract class that represents a block of other memory, including possibly unmanaged memory. It implements IDisposable already so you can just plug into this.

The Memory<T> struct can optionally internally point to a MemoryManager instance allowing you to plug your perfered style of allocation and freeing of memory into parts of the framework.

There is a little irony that a MemoryManager<T> is itself a class and therefore managed on the gc-heap, but you can defeat this by using ObjectPool<T> to recycle those instances to keep allocation count steady state and not trigger the GC.

I have used this before (in the toy database i mentioned earlier) to allocate aligned blocks of unmanaged memory.

[0] https://learn.microsoft.com/en-us/dotnet/api/system.buffers....

How?

I know of constraints on generic type parameters, but not how to do this. A cursory search is unhelpful.

e.g.

  interface Foo {
    int Calculate();
  }

  static void CalculateThing<T>(T impl)
  where T: Foo {
    var num = impl.Calculate() * 2;
    Console.WriteLine(num);
  }

You can apply additional constraints like `where T: struct` or `allows ref struct`. The last one is a new addition which acts like a lifetime restriction that says that you are not allowed to box T because it may be a ref struct. Ref structs are for all intents and purposes regular structs that can hold so-called "managed references" aka byrefs, which have syntax 'ref T', which is discussed in detail by the article this submission links to (ref structs can also hold other ref structs, you are not limited in nesting, but you are limited in cyclicality).

As for delete operator, 'dispose' works well enough. I have a toy native vector that I use for all sorts of one-off tasks:

  // A is a shorthand for default allocator, a thin wrapper on top of malloc/realloc/free
  // this allows for Zig-style allocator specialization
  using var nums = (NVec<int, A>)[1, 2, 3, 4];
  nums.Add(5);
  ...
  // underlying pointer is freed at the end of the scope

This retains full compatibility with the standard library through interfaces and being convertible to Span<T>, which almost everything accepts nowadays.

System-provided allocators are slower at small allocations than GC, but Jemalloc easily fixes that.

I missed this development! That was a big pain working with ref structs when they first came out.

List<int> nums = [1, 2, 3, 4];

//do stuff with nums

Delete(nums);

In addition, objects that hold references to other objects internally would need an implementation that would allow to traverse and recursively free references in a statically understood way. This gets nasty quick since a List<T> can hold, let's say, strings, which may or may not have other locations referring to them. Memory safety goes out of the window for dubious performance wins (not even necessarily, since this is where GC has better throughput).

I can recommend watching the lectures from Konrad Kokosa that go into the detail how .NET's GC works: https://www.youtube.com/watch?v=8i1Nv7wGsjk&list=PLpUkQYy-K8...

In my comment I already suggested a context where GC can be turned off. I said: "It would be better if the GC can be turned off with a switch and just add a delete operator to manually free memory."

Also there is C++ for that, if the goal is to use C# as C++.

This really is a PoC. You might get better results by using snippets as the inspiration for rolling something tailored to your specific use-case.

This breaks the fundamental assumptions built into pretty much every piece of software ever written in the language - it's a completely inviable option.

Incorporating a borrow checker allows for uncollected code to be incorporated without breaking absolutely everything else at the same time.

Unfortunately, as usual in computing, we have to do huge circles shaped in zig-zag, instead of adopting what was right in front of us.

Lots of zig-zags.

I am a firm believer that if languages like Java and C# had been like those languages that predated them, most likely C and C++ would have been even less relevant in the 2010's, and revisions like C++11 wouldn't have been as important as they turned out to be.

Also, can't miss the opportunity to bring up Graydon's iconic 2010 talk "Technology from the past come to save the future from itself". http://venge.net/graydon/talks/

It seems more relevant than ever to study the fundamental discoveries made in the early history of Windows. We don't know the magnitude of how much the rendering API affects the success of an operating system. It would be safe for a novel OS to heed the importance of the rendering API.

But more abstractly, it could be that the best novel OS competitor to Windows is simply the open-source flavor. It would be stronger evidence to see someone building Windows 1.0 in a modern sense, stronger than any other evidence, that a serious competitor is incoming.

The next OS won't be written in Javascript (sorry React).

So even those that weren't initially exposed in unsafe mode, were available at the MSIL level and could be generated via helper methods making use of "System.Reflection.Emit".

Naturally having them as C# language features is more ergonomic and safer than a misuse of MSIL opcodes.

In case anyone is interested, here is the spec about refs in structs and other lifetime features mentioned in the article:

https://github.com/dotnet/csharplang/blob/main/proposals/csh...

And here is the big list of ways .NET differs from the publish ECMA spec. Some of these differences represent new runtime features.

https://github.com/dotnet/runtime/blob/main/docs/design/spec...

Using C/C++/Rust to do the same task is probably more productive than emitting MSIL opcodes, so that solution wasn't really that practical.

But with these new features being more ergonomic and practical, it becomes cost effective to just do it in C# instead of introducing another language.

Also P/Invoke and CCW/RCW do have costs cross the runtime layer, even if minor when compared with other languages.

On NativeAOT, you can instead use "DirectPInvoke" which links against specified binary and relies on system loader just like C/C++ code would. Then, you can also statically link and embed the dependency into your binary (if .lib/.a is available) instead which will turn pinvokes into direct calls (marshalling if applicable and GC frame transition remain, on that read below).

Lastly, it is beneficial to annotate short-lived PInvoke calls with [SuppressGCTransition] which avoids some deoptimizations and GC frame transition calls around interop and makes the calls as cheap as direct calls in C + GC poll (a single usually not-taken branch). With this the cost of interop effectively evaporates which is one of the features that makes .NET as a relatively high-level runtime so good at systems programming.

Unmanaged function pointers have similar overhead, and identical if you apply [SuppressGCTransition] to them in the same way.

* LibraryImport is not needed if pinvoke signature only has primitives, structs that satisfy 'unmanaged' constraint or raw pointers since no marshalling is required for these.

If anything, article doesn't talk about MSIL or CLR, but C# language features. CLR is not the only target C# supports.

NativeAOT is supported in Avalonia (cross-platform UI framework), Razor Slices (dynamically render HTML from Minimal APIs) and I think there is also some support for AOT in MonoGame & FNA (game dev frameworks).

However, it's still early and a lot of the ecosystem doesn't support NativeAOT.

Native AOT depends on CLR infrastructure.