Written by Clive Tong (a Software Engineer at Red Gate who spends a lot of time enthusing about functional languages), and republished with permission of Simple-Talk Publishing, Copyright © 2011). This article is part of the ongoing “Ricky Leeks” education campaign, which is focused on fresh .NET Memory management knowledge. .NET Memory management is an impressively complex process, and most of the time it works pretty well. However, it’s not flawless, and neither are we developers, so memory management problems are still something that a skilled developer should be prepared for. And while it’s possible to have useful information about .NET memory management and write better code without fully understanding the black box inside the framework, there are a few common misconceptions which need to be dispelled before you can really get started:
Misconception #1: A Garbage Collector collects garbageThe run-time system has a notion of objects which it thinks it’s going to touch during the rest of its execution, and these are called the "live", or reachable objects. Conversely, any object which isn’t live can be regarded as "dead", and obviously we’d like to be able to reuse the memory resources that these dead objects are holding in order to make our program run more efficiently. So it is perhaps unintuitive that the focus of the .NET Garbage Collector (the GC, for short) is actually on the non-garbage; those so-called Live Objects. One of the essential ideas behind the GC strategies that most people implement is that most objects die young. If you analyze a lot of programs, you find that, typically, a lot of them generate temporary objects while they’re doing some calculation, and then produce some other object to represent the results of that calculation (in some fashion). A lot of these young objects are therefore temporary, and are going to die quite quickly, so you want to design your GC to collect the dead items without having to process them all individually. Ideally, you’d like to only walk across the live objects, do something with those to keep them safe, and then get rid of all the objects which you now know are dead without going through them all one by one.
Read more: Codeproject
QR:
- A garbage collector collects garbage
- Doing lots of gen0 collections is bad
- Performance counters are great for understanding what is happening
- .NET doesn’t leak memory
- All objects are treated the same
Misconception #1: A Garbage Collector collects garbageThe run-time system has a notion of objects which it thinks it’s going to touch during the rest of its execution, and these are called the "live", or reachable objects. Conversely, any object which isn’t live can be regarded as "dead", and obviously we’d like to be able to reuse the memory resources that these dead objects are holding in order to make our program run more efficiently. So it is perhaps unintuitive that the focus of the .NET Garbage Collector (the GC, for short) is actually on the non-garbage; those so-called Live Objects. One of the essential ideas behind the GC strategies that most people implement is that most objects die young. If you analyze a lot of programs, you find that, typically, a lot of them generate temporary objects while they’re doing some calculation, and then produce some other object to represent the results of that calculation (in some fashion). A lot of these young objects are therefore temporary, and are going to die quite quickly, so you want to design your GC to collect the dead items without having to process them all individually. Ideally, you’d like to only walk across the live objects, do something with those to keep them safe, and then get rid of all the objects which you now know are dead without going through them all one by one.
Read more: Codeproject
QR: