Memory leaks in managed code?

[Kev]

I've been trying to understand the article "Identifying Memory Leaks in
the Common Language Runtime" listed on http://support.microsoft.com/?id=318263

It says "The garbage collector can
collect and free the memory but never returns it to the operating system.
This occurs when the garbage collector cannot move the objects that are
still in use to one portion of the memory and free the rest."

How can this happen? I know the basics of garbage collection and memory
deallocation, but I don't understand how and why the GC would move around
free blocks and objects. Is the only goal consolidation of free space?

Also, what's the difference betweeen point #2 ("Memory is disposed of but
never collected, because a reference to the object is still active.") and
point #4 ("Poor memory management can result when many large objects are
declared and never permitted to leave scope.")?

And finally, are there any good resources to help understand the inner
workings on the CLR garbage collector? (I'm a .NET beginner!) Does the CLR GC use
"pinning", or does it use something else?

Thanks.

Kevin

 

[Wessel Troost]

How can this happen? I know the basics of garbage collection and memory

deallocation, but I don't understand how and why the GC would move
around free blocks and objects. Is the only goal consolidation of free
space?

You allocate memory from the OS in blocks. The entire block has to be
free before you can return it to the operating system. So, it makes sense
to free up block by consolidating memory.

Also, what's the difference betweeen point #2 ("Memory is disposed of
but never collected, because a reference to the object is still
active.") and point #4 ("Poor memory management can result when many
large objects are declared and never permitted to leave scope.")?

Point #2 is for example, when two objects have a reference to eachother.
They will never be collected.

Point #4 is something different entirely, like a static variable in a
function which references a huge object.

And finally, are there any good resources to help understand the inner
workings on the CLR garbage collector? (I'm a .NET beginner!) Does the
CLR GC use "pinning", or does it use something else?

The book from Jeffrey Richter has a nice explanation. See
http://safari.oreilly.com.

Greetings,
Wessel

 

[brett]

Which specific book by Jeffrey Richter are you referring to?

Thanks,
Brett

 

[Wessel Troost]

"Applied Microsoft .NET Framework Programming"
chapter 19, "Automatic Memory Management (Garbage Collection)"

Greetings,
Wessel

 

[Willy Denoyette [MVP]]

Inline

Willy.

You allocate memory from the OS in blocks. The entire block has to be
free before you can return it to the operating system. So, it makes sense
to free up block by consolidating memory.

These blocks are called segments and the CLR uses segment sizes of 32 MB for
the workstation GC and 64MB for the server GC.
But keep in mind that the CLR never returns the initial (2) segments
allocated, only additional segments are ever returned to the OS.

Point #2 is for example, when two objects have a reference to eachother.
They will never be collected.

This is not true, cycles are correctly collected by the GC.

 

[Christof Nordiek]

I've been trying to understand the article "Identifying Memory Leaks in
the Common Language Runtime" listed on
http://support.microsoft.com/?id=318263

</snip>

Also, what's the difference betweeen point #2 ("Memory is disposed of but
never collected, because a reference to the object is still active.") and
point #4 ("Poor memory management can result when many large objects are
declared and never permitted to leave scope.")?

</snip>

These four points in the article are about memory leak in general, not
specific for .NET.

Christof

 

[Wessel Troost]

Point #2 is for example, when two objects have a reference to eachother.

This is not true, cycles are correctly collected by the GC.

Could you elaborate on that?

Greetings,
Wessel

 

[Willy Denoyette [MVP]]

Could you elaborate on that?

Greetings,
Wessel

Sure, but I guess you better start reading this:
http://msdn.microsoft.com/msdnmag/issues/1100/GCI/default.aspx
especially the Garbage Collection algorithm chapter explains how the GC
tracks the reachable objects and builds an object graph starting from a
"root". Objects that are no longer "rooted", be it directly or indirectly,
are considered garbage and will be collected.

Willy.

 

[Wessel Troost]

Sure, but I guess you better start reading this:

http://msdn.microsoft.com/msdnmag/issues/1100/GCI/default.aspx

Thanks for the pointer, nice article, looks like the chapter from "Applied
Microsoft .NET Framework Programming" tho

especially the Garbage Collection algorithm chapter explains how the GC
tracks the reachable objects and builds an object graph starting from a
"root". Objects that are no longer "rooted", be it directly or
indirectly,
are considered garbage and will be collected.

Agreed, the example I gave would be collected. I was back thinking in COM
terms, when each object had a reference counter.

Greetings,
Wessel

 

[Willy Denoyette [MVP]]

Inline
Willy.

Thanks for the pointer, nice article, looks like the chapter from "Applied
Microsoft .NET Framework Programming" tho

Yep, same author isn't it?
Note that while I agree that it's a nice article, it's also a bit outdated,
so not all what's written in there is still correct. More detailed/accurate
articles are written by members of the CLR team, like the highly recommended
reading here:
http://blogs.msdn.com/maoni/default.aspx