Memory leaks in managed code?

  • Thread starter Thread starter Kev
  • Start date Start date
K

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
 
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?
Click to expand...
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.")?
Click to expand...
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?
Click to expand...
The book from Jeffrey Richter has a nice explanation. See
http://safari.oreilly.com.

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

Greetings,
Wessel
 
Inline

Willy.

Wessel Troost said:
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.
Click to expand...

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.
Click to expand...

This is not true, cycles are correctly collected by the GC.
 
I've been trying to understand the article "Identifying Memory Leaks in
the Common Language Runtime" listed on
http://support.microsoft.com/?id=318263
Click to expand...
</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.")?
Click to expand...
</snip>

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

Christof
 
Point #2 is for example, when two objects have a reference to eachother.
This is not true, cycles are correctly collected by the GC.
Click to expand...

Could you elaborate on that?

Greetings,
Wessel
 
Wessel Troost said:
Could you elaborate on that?

Greetings,
Wessel
Click to expand...

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.
 
Sure, but I guess you better start reading this:
http://msdn.microsoft.com/msdnmag/issues/1100/GCI/default.aspx
Click to expand...

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.
Click to expand...
Agreed, the example I gave would be collected. I was back thinking in COM
terms, when each object had a reference counter.

Greetings,
Wessel
 
Inline
Willy.

Wessel Troost said:
Thanks for the pointer, nice article, looks like the chapter from "Applied
Microsoft .NET Framework Programming" tho :-)
Click to expand...

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
 
Back
Top