Deterministic deletion of the managed object

Srinivas Sripathi

In .net, the unmanaged resources like file handles, database connections, etc... can be deleted or freed at any time through the dispose method. But there is no way for the determinstic deletion of the managed objects. The managed objects are deleted by the garbage collector only when it runs. we can not predict when the GC runs. It runs when the generations are full based on the generation algorithm. The main problem of not having the deterministic deletion of the managed objects to which there are no further references existing in the program is that they occupy the main memory unnecessarily till the time the GC runs even though there is no use of them.
The memory management job has been taken from the developer and given to the GC to get rid of 2 problems which troubled the unmanaged c++ programmers a lot. They are 1. Memory leaks and 2. Access violations.
The reason behind not providing the deterministic deletion of the managed objects to the developer is to avoid access violations. That is good and safe. But it causes the above problem. It would be better if there is any other approach to avoid the access vioaltions while providing a way to the developers to delete the managed objects.

6 Replies

Know the answer? Post it — somebody with the same question will find it here.

Vulpes15y ago
Accepted answer
It only deletes objects to which there are no longer any references in the current process. Notice though that in .NET there may be several 'application domains' in a single process and so the GC would collect unused objects from all of them.
Srinivas Sripathi15y ago
Vulpes, Thanks for the explanation. GC.Collect looks like the one way to do the determinstic deletion of the managed objects. I have a question on this. Does this method delete the objects of the process in which it is called or the objects that are not having any references in all processes that are presently alive in the runtime?
Vulpes15y ago
You can force a garbage collection by calling the GC.Collect() method (see http://msdn.microsoft.com/en-us/library/xe0c2357.aspx).

However, there are only a few occasions when you need to because garbage collections occur quite frequently and are not usually noticeable. One such occasion is when you're writing a real-time application and you don't want the GC to kick in whilst you're doing a critical operation. You can then call GC.Collect() just before doing the critical operation.

No system is perfect but I've been using .NET now for 10 years and have never found automatic GC to be a problem. It allows me to concentrate on the logic of the program rather than the system plumbing and is certainly a lot better than the vagaries of reference counting in COM programming.
Sam Hobbs15y ago
What is the question?
Srinivas Sripathi15y ago
I want to use C#. I posted this question to know whether there is any workaround to this problem or not. If yes and you know that please tell me.
Sam Hobbs15y ago
Is someone telling you to use C#? Then you need to discuss this with them. Otherwise if you don't like C# then don't use it. Thousands of developers use C# and this won't convince them not to.