Understanding the GC

[Mike Parker]

On Wednesday, 30 January 2013 at 06:00:44 UTC, Jeremy DeHaan 
wrote:

>
> From what I understand, when an object is recovered by the GC, 
> the destructor may or may not be called. Why is that? Is it for

That's not quite correct. When the object is collected, its 
destructor will be called. But you have no control over when or 
if it will happen during runtime. More on this below in relation 
to your question about unreferenced objects.


> performace reasons? What about the destructors of objects that 
> the original object contained? Are they called when the item 
> finally get's taken care of by the GC, or when the object is 
> originally recovered by the GC?

Destructors of members will not be called when an object is 
collected. Only that of the object itself. But, there's no 
guarantee that any member references will still be valid when the 
object's destructor is called. See below for more.

>
> My other question is, at the end of the program will GC go 
> through every object it knows still holds memory and call their 
> destructors? My guess is that it does so that the GC ensures

Yes.

> all memory is successfully released before the program ends. I 
> just want to make sure since in http://dlang.org/class.html, it 
> says, "The garbage collector is not guaranteed to run the 
> destructor for all unreferenced objects." What exactly is an 
> unreferenced object?

A "referenced" object is one that is still in use by the program. 
Example:

auto mc = new MyClass;

// Here, there is exactly one reference to the MyClass instance
// and it is still active.

// But if i do this...
auto mc2 = mc;

// Now there are 2 references to the same instance.
// Set one to null.
mc = null;

// Now there is only one reference. Null it...
mc2 = null;

// Now all references to the original instance are invalid,
// so the object is unreachable by the program, so it is an
// unreferenced object.

The GC can only collect objects that it can be sure are 
unreferenced. Sometimes it can't be sure, in which case that 
particular object won't be collected during run time. For the 
objects that are determined to be collectable, there's no way to 
guarantee that any one of them will be collected in any given 
collection cycle. Because of that, you cannot rely on the order 
of destruction. Consider:

class Foo {}
class Bar { Foo f; }

Bar b = new Bar;
b.f = new Foo;

Given that b.f is the only reference to this Foo instance, then 
this instance of Foo will become unreferenced at the same time 
that the instance of Bar does. But, again, we cannot rely on the 
Bar instance being collected and destructed before the Foo 
instance. So if you have a Bar destructor that tries to access a 
member in f, then you would get a crash some of the time. Worse, 
what if there were more references to the Foo instance outside of 
Bar that haven't been released yet? If you tried to destroy f 
from the Bar destructor, or perhaps call some sort of cleanup 
method to release system resources that f controls, you'll get a 
crash somewhere else in the program when another bit of code 
tries to access the no longer valid reference. That would likely 
be a marathon debugging session, because most of the time you 
don't expect that sort of thing.

>
> Some other questions:
>
> At what point is the GC called to do it's thing while the 
> program is running? Is it at certain intervals or is it when 
> the program's memory reaches a certain point?

My understanding is that the current implementation only runs 
collections when memory is allocated. Meaning, when you allocate 
a new object instance, or cause memory to be allocated via some 
built-in operations (on arrays, for example), the GC will check 
if anything needs to be collected and will do it at that time. I 
don't know if it's run on every allocation, or only when certain 
criteria or met, and I really don't care. That's an 
implementation detail. The D language itself does not specify any 
of that.