| Author: D.Jeya kumar(JK) 28 Aug 2008 | Member Level: Diamond | Rating: Points: 5 |
Hi,
CLR will have a regular check for the Unsed objects in that application while running the application. Frequently it will check and dispose the unsed objects . but Automatic Diposal of the values will take some time.
We can call GC.Collect() to call the grabage colllector manually to free the memory of the unused objects.
Check the below site to know more about it
http://msdn.microsoft.com/en-us/magazine/bb985010.aspx
Regards JK
|
| Author: Legend 29 Aug 2008 | Member Level: Silver | Rating: Points: 6 |
1. The Problem Domain – Memory Management
1) Applications composed of components / libraries written by different developers at different points in time 2) These components have no idea of resources are allocated / released by each other – they are only aware of how they manage resources themselves 3) The substrate needs to provide a common memory management infrastructure which would let these components work with each other 4) The mechanism used should * Be optimal on memory utilization * Provide strong object locality to take get cache efficiency and take advantage of CPU Registers & Caches * Ensure code correctness * Minimize the burden on the developer * Support scenarios like Finalization, Weak References and Pinning
2. Memory Management – What are the Choices?
2.1 Reference Counting Each component keeps a count of number of clients using it and destroys itself when the last client Releases it * Example: COM, Number of large-scale C++ projects * Depends on components and clients keeping a correct count, mistakes can lead to a memory leak (accumulation of unreferenced objects) or premature releasing * Difficult to resolve circular references
2.2 Garbage Collection - Mark and Sweep * Example: C Runtime Heap * Initially, allocate objects on the heap sequentially * At some stage, mark the objects that are dead and can be removed * Free the dead object slots at some stage 1) In C/C++ the programmer has to do it since the runtime can be misled about object size by type-casting, void pointers, etc. 2) Environments like CLR where type safety is guaranteed are always aware of object size and can free memory on their own * Maintain a list of free slots (Free List) * On next allocation request traverse the list and give the smallest possible slot that can fulfill the memory allocation request * Advantage: Minimal house-keeping overhead (just one freelist) * Disadvantage: Every allocation request requires a walk thru the freelist, makes allocations slow * Disadvantage: Heap fragmentation – there may not be a single contiguous block to accommodate a request for a large block
2.3 Garbage Collection – Copy and Collect * Keep two heaps * Allocate only from one heap * When collection is triggered on the heap, copy all alive objects to the second heap * Switch the roles of heaps * Advantage: Conceptual Simplicity * Disadvantage: Copy operation needs to be done for all objects * Disadvantage: Blocks a lot of memory unneccessarily
2.4 Garbage Collection – Mark and Compact * Example: CLR, some JVM implementations * Same as Mark and Sweep except that as free space from dead objects is claimed, the alive objects are compacted together to leave a single contiguous block of free memory * Disadvantage: Compacting memory can be expensive for large objects * Advantage: Allocation requires just a pointer to keep track of the top of the heap, so it is lightning fast * Advantage: No heap fragmentation
please Refer the link to continue
http://vineetgupta.spaces.live.com/blog/cns!8DE4BDC896BEE1AD!1104.entry
|