C# HUGE omission: no method call on zero references (like destructor)

[iperov]

The era of immutable data has begun.

What does that mean?
For example immutable object Image() has allocated memory.
in C# If I call a transform chain like .blur(...).contrast(...).resize(...) it will create 3 copies of the modified images, and the allocated memory from .blur() will not be freed after contrast() on reference loss, but will accumulate, and will be freed maybe after an hour.
This is not acceptable in 2k25.

The Image example is not the only one. Similarly, you can wrap GPU memory (tensors as in ML libraries), and perform operations. In GPU there is no way to wait even 1 second for memory to be freed, because memory is small and will quickly run out in hundreds of operations.

The code as .blur(...).contrast(...).resize(...) looks minimalistic and clear.
Even python calls __del__() on reference loss, allowing you to free memory on the fly without waiting for GC.

Currently in C# you can only handle this by explicitly calling using or dispose, which is bullshit because 3 one-line operations .blur(...).contrast(...).resize(...) would then take 9 lines.
This is why C# lost the ML race without even entering it because of this serious flaw.

You should have 5 years ago added the ability to call code when references are lost to zero, for example override Object.OnReferenceLose().

[HaloFour]

I believe this is more a runtime question. The C# language specification does not specify what kind of garbage collection algorithm the runtime should provide, only that objects may be eventually deallocated when there are no more references. That does not seem to preclude a reference counting algorithm that would free immediately.

[IS4Code]

That's what virtually all modern programming languages use.

Also, as has been pointed out, C# does not care about how garbage collection works. This is on .NET.

[iperov]

I even just allocate heaps of memory in a loop, and at some point everything went into tens of gigabytes and won't free up.

class Some11
{
    byte[] x;

    public Some11()
    {
        x = new byte[16 * 1024 * 1024];
    }

    ~Some11()
    {
        Console.WriteLine("asd");
    }
}

static class Program
{

    static void asd()
    {
        Some11? x = null;
        while (true)
        {
            Console.WriteLine("1");
            x = new Some11();
        }

How is this even possible in 2k25?
I don't understand what could be more logical than calling the destructor as soon as no one else owns the reference? Why did they invent this nonsense mark and sweep?

[huoyaoyuan]

Finalizer has its own queue to be invoked. The allocated array can only be collected at the next GC after the destructable object get finalized. As each objects holds 16 MB of memory, 10GB is just less than 1000 objects. It's very common to have thousands of objects pending for collection in GC-based system. Moreover, array of 16MB is allocated on the large object heap, which is collected less frequently.

Finalizer is not destructor. If you remove the finalizer, the memory consumption will be consistently less than 100MB.

[yaakov-h]

That's also using the workstation GC by default, I believe. Server GC should drop the memory consumption a bit more aggressively.

[huoyaoyuan]

To compare in ways how people would write program:

class Holder
{
	char* ptr;

public:
	Holder() : ptr(nullptr) {}

	explicit Holder(size_t s)
	{
		ptr = new char[s];
	}

	~Holder()
	{
		delete[] ptr;
	}
};

void Test()
{
	std::vector<std::shared_ptr<Holder>> alive;
	alive.resize(1000);

	LARGE_INTEGER start, end;
	QueryPerformanceCounter(&start);
	for (int i = 0; i < 1000000; i++)
	{
		alive[i % 1000] = std::make_shared<Holder>(1000 + (i % 7) * 10);
	}
	QueryPerformanceCounter(&end);
	std::cout << end.QuadPart - start.QuadPart << " Ticks\n";
}

int main()
{
	while (true)
	{
		Test();
	}
}

void Test()
{
    Holder[] alive = new Holder[1000];

    long start = Stopwatch.GetTimestamp();

    for (int i = 0; i < 1000000; i++)
    {
        alive[i % 1000] = new Holder(1000 + (i % 7) * 10);
    }

    long end = Stopwatch.GetTimestamp();

    Console.WriteLine($"{end - start} Ticks");

}

while (true)
{
    Test();
}

public class Holder(int size)
{
    byte[] array = new byte[size];
}

The unoptimized C# program (~420000 Ticks) simply outperforms the reference counting-based C++ program (~550000 Ticks). GC is very performant for how real-world application allocates memory: various sizes of small objects, some randomly lives longer.

[CyrusNajmabadi]

You should have 5 years ago added the ability to call code when references are lost to zero, for example override Object.OnReferenceLose().

This does not appear to be a C# issue afaict. You could consider opening a discussion with teh runtime. They are the team that would have some concept of if an instance is 'referenced' and if/when those references are 'lost'.

[ds5678]

If these are common operations for you, you should just write some extension methods.

public static Image BlurAndDisposeCaller(this Image caller)
{
    var result = caller.blur();
    caller.Dispose();
    return result;
}

[iperov]

are you serious? 🤣

[yaakov-h]

You could also write the library in such a way that you chain the operations and then apply them all at once, or in a series of passes over the same image data. There's no hard requirement in computer science for each mutation of an image to produce a new copy of the image in the first place.

e.g.

var newImage = image.Transform([Blur(...), Contrast(...), Resize(...)]);
// or
var newImage = image.Blur(...).Contrast(...).Resize(...).Apply();

[iperov]

yeah it's called graph based transformation. Tensorflow used the same approach but did not gain popularity. Now all research is written in pytorch. Tensorflow is dead.

[ds5678]

are you serious? 🤣

It's a solution that can be used today. In your dream scenario where the language team decides to implement your idea (which won't happen because it's a runtime request), you would be waiting a minimum of 18 months because it's too late for it to be made part of C# 14.

[CyrusNajmabadi]

As mentioned:

1. GC versus referencing counting are not decisions within the language. They are a runtime decision. So this is not an appropriate venue for this discussion.

2. GC often excels over reference counting. So you'd need to make a pretty compelling case, with data, demonstrating the problem, and motivating ref counting as a solution.

Regardless, this is not something the language cares about unless the runtime wants to do something special and believes there should be some special syntax to work with the ref counting system.

My recommendation is that if you want to continue this, take it to the dotnet/runtime repo.