View mode: basic / threaded / horizontal-split · Log in · Help
August 28, 2010
Memory management and garbage collectors
In theory, garbage collectors make memory leaks a thing of the past.  In 
practice, garbage collectors don't always work according to theory.  This 
makes me curious:  how does one test for memory leaks in a D program?

I also don't know how smart or dumb garbage collectors are.  How much help 
does it need?  Okay, that is too general a question.  So take a for-
instance.  Consider a circular linked list that we are done with.  Each 
node has a reference to it (from another node in the list).  But, being 
done with the list, we imagine that there are no references from outside 
the list to any node.  Is D's garbage collector smart enough to deal 
recognize the circle of nodes as garbage?  Is it necessary or at least 
helpful to set all the circle's links to null before being done with it?  I 
assume that reference counting collectors are not smart enough to handle an 
abandoned circular list.  But D's GC is not a reference counter.  I don't 
know how smart GC's get.  Is it okay to leave a single node linking to 
itself?

Another for-instance.  Consider this time a linear linked list.  This time,
the list is finite: it terminates with a node pointing to null.  Are the 
issues here any different?

Thanks in advance for any insights.
August 28, 2010
Re: Memory management and garbage collectors
JMRyan:
> In theory, garbage collectors make memory leaks a thing of the past.

Even with a perfect GC you may leave around references that keep alive some data that you will never need to use. This is a kind of memory leak.

And the current D GC is not fully precise, this means that sometimes it sees as possible pointers even stuff that is not a pointer, so noise may keep alive memory blocks that are not really referenced.


> So take a for-
> instance.  Consider a circular linked list that we are done with.  Each 
> node has a reference to it (from another node in the list).  But, being 
> done with the list, we imagine that there are no references from outside 
> the list to any node.  Is D's garbage collector smart enough to deal 
> recognize the circle of nodes as garbage?

It's not a matter of being smart, it's a matter of how its algorithm works. In a GC based on reference counts, you keep an object alive if its count is nonzero, this means if one or more references point to it.

In a GC like the D one (well, in a basic implementation of its idea), you have some starting pointers, the roots, and starting form them you explore the graph of the references, and along the way you mark the visited objects. At the end you scan the list of all the objects and delete the ones with no mark. So the presence of a cycle is not a problem. A cycle is recycled if no external pointers point to it.

CPython GC is a reference counter, but they have added extra logic to recognize and recycle cycles too.

I leave other of your questions to other people.

Bye,
bearophile
August 31, 2010
Re: Memory management and garbage collectors
Thank you for your reply.  It was helpful.
Top | Discussion index | About this forum | D home