I explicitly mentioned how moving into a background thread is poor man's tracing GC.
Languages like D and C# offer mechanisms for deterministic deallocation, while keep the productivity of a tracing GC.
Then there native memory allocation and safe handles.
IDisposable and Finalizers aren't the same thing, actually, although they happen to be used together as means to combine deterministic destruction alongside GC based destruction.
You can also make use of lambdas or implicit IDisposable implementations via helper methods, that generate code similar to memory regions or arenas in C++, but in .NET.
Finally, many tend to forget that .NET was designed to support C++ as well, so it is also possible to generate MSIL code that ensures deterministic destruction RAII style, naturally this falls into a bit more advanced programming, but it can be hidden away in helper classes.
Well, not really. You cannot stack allocate anything but primitive buffers. So no objects or even strings. So it cannot replace heap allocation for anything but smallish "arrays" of simple types like char and int. This also means you can't use normal structs/value types, only primitives.
> You can also make use of lambdas or implicit IDisposable implementations via helper methods, that generate code similar to memory regions or arenas in C++, but in .NET.
> Finally, many tend to forget that .NET was designed to support C++ as well, so it is also possible to generate MSIL code that ensures deterministic destruction RAII style, naturally this falls into a bit more advanced programming, but it can be hidden away in helper classes.
I'm pretty sure there is no way in C# or in MSIL to explicitly free/deallocate a heap allocated object.
MSIL defines a Newobj opcode, but no Freeobj or anything like it that I have ever seen. You can use custom allocators or unmanaged memory to deterministically allocate and free buffers of structs/values types. But only those that do not include references to managed object references, otherwise you would need to pin and the references yourself and keep the GC aware that there were non-tracked references to those objects. It gets messy fast.
As for stack allocation, apparently you missed structs.
Here is your string allocated on the stack.
unsafe struct cppstring
{
const int BuffSize = 1024;
fixed char data[BuffSize + 1];
int current;
public cppstring(System.ReadOnlySpan<char> buffer)
{
for (int i = 0; i < System.Math.Min(BuffSize, buffer.Length); i++)
data[i] = buffer[i];
current = 0;
}
}
public class StackDemo {
public void Myfunc() {
var str = new cppstring ("Hello from stack");
}
}
Yes I realize they can be used to store the same data, but you've defined a new type that is incompatible with an actual string object.
And when their count reaches 0, you have your stop the world, unless you move the destruction into a background thread, thus manually emulating a tracing GC.