Does garbage collection guarantee that a program will not run out of memory?

Question

Hi we want to know that Garbage collection concept give the full guarantee that my program will not run out of memory.

Senthilkumar · Answer

Hi, .Net CLR guaranteed that Garbage collection runs with in the boundary of memory. .Net framework garbage collector allocated and releases the objects from the memory. When every the object creation happens, it responsibility to allocate the memory. It will run the deallocation algorithm to release the object from the memory and allocates the space to the new objects. There are certain conditions to run the garbage collection, when ever the object allocation happens, memory pressure for the current objects. But the same time it ensures when the space is available then it will allocate the spaces for the managed heaps. The memory has the limit and the garbage collector optimization engine ensures that it will run in the boundary and manage the memory for the garbage collection. Because the memory is not indefinite. As a programmer we no need to bother about this issue, because microsoft has developed this component as inbuilt mechanism to handle this memory management for effective performance to the processor. I suggest you to go through this MSDN url for better understanding. http://msdn.microsoft.com/en-us/library/0xy59wtx.aspx

Vulpes · Answer

No, it can't do that as the amount of heap memory it has to work with is finite. If there is insufficient memory remaining to satisfy the amount needed for a new object, then the garbage collector will attempt to reclaim as much memory as possible by releasing memory used by objects to which there are no longer any references. However, if there's still insufficient memory, an 'out of memory' exception will be thrown. Notice also that objects larger than 64 KB (typically arrays, arraylists etc) are allocated in a separate part of the heap which is not compacted when other large objects are garbage collected. New large objects may therefore need to be alocated in the 'holes' between existing objects. If there isn't a large enough 'hole' available for a new object, this may therefore result in an 'out of memory' exception' even though there appears to be plenty available!