C# Manual delete object pointer

Question

Why not to create a possibility to delete objects in C# as in C++ as a alternative but not required action?

For example when we want to clean memory from 500 Mb object after it not necessary any more to not wait for GC(Garbage collector)

Answer 1

The whole point of a managed language such as .NET is, that there is a garbage-collector that deletes all the orphaned objects. These are all the objects to which no references exist. For example in the following example when program reaches the end of the DoSomething method, all references to the created object of type MyClass are lost and the object itself is marked for deletion. However the GC decides when to do this.

void SoSomething()
{
    var m = new MyClass();
}

So you don´t have to care for this much, unless you have some unmanaged resources, which GC can´t handle at all.

So you seem to have some big design-problem in your program. You either have far too many objects in GC-state 2 which are long-lived and thus not collected (static variables for example), or there are many unmanaged resources such as file-handlers which GC can´t handle.

In the first case you should limit the scope of your variables as much as possible.

In the second case you should use the Dispose method for every such resource. This is easiest done with a using, which will call IDisposable.Dipose() automatically when an exception occurs or when the codeblock is done. Calling Dispose will ensure the unmanaged memory is released. However the remaining managed part of the object still remains in memory. However this will soon be garbage-collected as soon as all the references to it are gone, hence the importance of variable scope.

using (FileStream fs = File.Create(path))
{
    // do something with the file
}

Answer 2

You can use GC.Collect(); to force a collection by the Garbage Collector, but this is normally not recommended unless you have a good reason and you know what you're doing.

If you have a way to reach the object you want to destroy, it is actually impossible to destroy that object - the collector will not collect an object that is reachable.

If the object you want to destroy is an unmanaged object, then wrap it with using or remember to dispose of it.

Answer 3

I will add my 50 cents regarding GC. If you have lots of large unmanaged objects .NET does not know that you eat much memory and you need to add Memory Pressure to notify how many bytes are allocated in reality:

GC.AddMemoryPressure(long bytes)

An example can be found here:

http://adavesh.blogspot.com/2012/02/gcaddmemorypressure-working-with-native.html

Answer 4

If the object you are working with implements IDisposable within its class then you can call my_object.Dispose(); to manually remove memory allocation.

You can also force the garbage collector to run using System.GC.Collect() though this is not recommended.

Answer 5

This is how generational GC works. Unlike C++ it doesn't have map of free space to allocate new object. It just allocates new objects down the memory space after previous allocation. When GC happens, objects that still needs to be kept in memory are compacted and physically moved in memory.

So, even if you could deallocate single object memory allocator won't use that memory segment until next GC happens and it makes no sense to deallocate just one object.

Of course, there are more details in GC like different generations, Large objects heap, multiple segments for generations, but overall removing just one object is useless.

Answer 6

In languages that allow objects to be explicitly freed, it is possible for a reference to a freed object to spontaneously become a seemingly-valid reference to an unrelated object. For example, in C, given:

FILE *f = fopen("file1", "w");
...
fclose(f);
FILE *g = fopen("file2", "w");
...
fprintf(f,"Hey there!");

it's possible that by the time the fprintf is performed, the FILE identified by f will have been recycled for use with file2. In general, there is no cheap way for a language to guard against such mistakes.

One of the major benefits of a reachability-based GC is that such a thing simply cannot happen. If one performs:

someStreamType f = openStreamSomewhow(...);
f.Dispose();
someStreamType g = openStreamSomewhow(...);
f.outputData(...);

then at the time outputData is called, f will hold a reference to a disposed stream object. As long as any copy of that reference exists anywhere in the universe, it will continue to identify that same dead object.

Neither Java nor .NET can safely recycle the storage used by an object unless they can be certain that no references to it exist. Making such determination for a large number of objects simultaneously is much cheaper than making it for individual objects, so being told that it's likely that no references to some particular object will exist wouldn't really be very helpful.