Why is Foo never deallocated here? (DMD32 D Compiler v2.099.0-dirty win64)

class Foo {
	string s;
	static size_t count, alloced, dealloced;
	this() {
		"+Foo".writeln;
		count++;
		alloced++;
	}
	~this() {
		"~Foo".writeln;
		count--;
		dealloced++;
	}
}
class Bar {
	string s;
	static size_t count, alloced, dealloced;
	this() { count++; alloced++; }
	~this() { count--; dealloced++; }
}
void main() {
	static assert(__traits(classInstanceSize, Foo) == __traits(classInstanceSize, Bar));

	GC.collect();
	writeln(GC.stats.usedSize, " START");
	{
		new Foo;
	}
	foreach (i; 0 .. 4_000_000) {
		new Bar;
		if (Foo.dealloced)
			break;
	}
	writeln(GC.stats.usedSize);

	writeln("Foo: ", Foo.count);
	writefln("Bar: %,d (%,d - %,d)", Bar.count, Bar.alloced, Bar.dealloced);

	GC.collect();
	GC.minimize();
	writeln(GC.stats.usedSize, " END");

0 START
+Foo
89632
Foo: 1
Bar: 2,800 (4,000,000 - 3,997,200)
64 END
~Foo

On 9/15/22 1:12 PM, cc wrote:

In answer to your title question, no. It does not prioritize anything. If it thinks something is ready to be freed, it is freed. If it thinks something is not ready to be freed, it is not freed.

So why is it not deallocated? There is no requirement for a specific piece of garbage to be collected at any specific time. Maybe something is referring to it on a register, and that register is still present? Maybe it's stored it somewhere on the stack? Maybe there's a false positive from a stack variable that isn't a pointer? For whatever reason, the GC still thinks it's alive.

People pull their hair out a lot trying to explain why the GC does or does not free something. Sometimes it just works one way on some environments, and differently on others.

I'd recommend just forgetting trying to prove whether the GC works or not, or that it works a specific way. Unless you are having a specific problem with memory leaks or things that are being freed that shouldn't be, don't worry about it.

-Steve