An examination of .NET memory management

in recent years, there has been an increased focus on relying on the memory management given by Garbage Collectors. This can be seen in many college classes that have talked about how they have simplified this matter. With their increasing usage in Interpreted languages I can see how people would wish to focus on the program design and not so much the management of memory. However, I feel that the current garbage collectors used, particularly with the .net framework are ineffective at best.

Now before I continue, I will elaborate on what has prompted me to talk about this. Since September of last year I have been working on a project for one of the other members of the high council. For the most part, this project has worked pretty well. The one big issue however was the poor memory management from the .net framework.

The big issue at hand is this, the .net framework only uses garbage collector when memory is running out or when the program is not doing anything intensive. To me, this is hardly an optimal scenario and will make it run out of memory first. As a result of this, I am going against what Microsoft recommends and controlling many aspects of the memory myself to minimize the memory leaks inherit in their interpreter. There is only so much I can do though as the only way to get full control is to use unmanaged code, which would alienate other members of my team.

Overall, this experience has soured me on the garbage collection on many interpreters that are not proactive. Before people say garbage collection is good, then I want them to answer why they don't properly dispose of objects that are no longer in use?