Is it bad practice to depend on the .NET automated garbage collector?

by

@Justin

…so, to answer your question, No. It is not a bad practice to depend on the .NET Garbage Collector. Quite the opposite in fact.

It is a horrible practice to rely on the GC to cleanup for you. It’s unfortunate that you are recommending that. Doing so, can very likely lead you down the path of have a memory leak and yes, there are at least 22 ways you can “leak memory” in .NET. I’ve worked at a huge number of clients diagnosing both managed and unmanaged memory leaks, providing solutions to them, and have presented at multiple .NET user groups on Advanced GC Internals and how memory management works from the inside of the GC and CLR.

@OP:
You should call Dispose() on the DataTable and explicitly set it equal to null at the end of the loop. This explicitly tells the GC that you are done with it and there are no more rooted references to it. The DataTable is being placed on the LOH because of its large size. Not doing this can easily fragment your LOH resulting in an OutOfMemoryException. Rememeber that the LOH is never compacted!

For additional details, please refer to my answer at

What happens if I don’t call Dispose on the pen object?

@Henk – There is a relationship between IDisposable and memory management; IDisposable allows for an semi-explicit release of resources (if implemented correctly). And resources always have some sort of managed and typically unmanaged memory associated with them.

A couple of things to note about Dispose() and IDisposable here:

  1. IDisposable provides for disposal of both Managed and Unmanaged memory. Disposal of Unmanaged memory should be done in the Dispose Method and you should provide a Finalizer for your IDisposable implementation.

  2. The GC does not call Dispose for you.

  3. If you don’t call Dispose(), the GC sends it to the Finalization
    queue, and ultimately again to the f-reachable queue. Finalization
    makes an object survive 2 collections, which means it will be
    promoted to Gen1 if it was in Gen0, and to Gen2 if it was in Gen1.
    In your case, the object is on the LOH, so it survives until a full
    GC (all generations plus the LOH) is performed twice which,
    under a “healthy” .NET app, a single full collection is
    performed approx. 1 in every 100 collections. Since there is lots of
    pressure on the LOH Heap and GC, based on your implementation, full
    GC’s will fire more often. This is undesirable for performance
    reasons since full GC’s take much more time to complete. Then there
    is also a dependency on what kind of GC you’re running under and if
    you are using LatencyModes (be very careful with this). Even if
    you’re running Background GC (this has replaced Concurrent GC in CLR
    4.0), the ephemeral collection (Gen0 and Gen1) still blocks/suspends threads. Which means no allocations can be performed during this
    time. You can use PerfMon to monitor the behavior of the memory
    utilization and GC activity on your app. Please note that the GC
    counters are updated only after a GC has taken place. For
    additional info on versions of GC, see my response to

    Determining which garbage collector is running.

  4. Dispose() immediately releases the resources associated with your object. Yes, GC is non-deterministic, but calling Dispose() does not trigger a GC!

  5. Dispose() lets the GC know that you are done with this object and its memory can be reclaimed at the next collection for the generation where that object lives. If the object lives in Gen2 or on the LOH, that memory will not be reclaimed if either a Gen0 or Gen1 collection takes place!

  6. The Finalizer runs on 1 thread (regardless of version of GC that is being used and the number of logical processors on the machine. If you stick alot in the Finalization and f-reachable queues, you only have 1 thread processing everything ready for Finalization; your performance goes you know where…

For info on how to properly implement IDisposable, please refer to my blog post:

How do you properly implement the IDisposable pattern?

More Related Contents:

  1. Where Is Machine.Config?
  2. Why Large Object Heap and why do we care?
  3. What’s so wrong about using GC.Collect()?
  4. Why does a System.Timers.Timer survive GC but not System.Threading.Timer?
  5. What are the roots?
  6. Find out the size of a .NET object
  7. Does SqlCommand.Dispose close the connection?
  8. Are .net finalizers always executed?
  9. Clear controls does not dispose them – what is the risk?
  10. When is memory, allocated by .NET process, released back to Windows
  11. Under what circumstances, we need to call GC.Collect twice
  12. When should I dispose my objects in .NET?
  13. What is the difference between .NET Core and .NET Standard Class Library project types?
  14. How Random is System.Guid.NewGuid()?
  15. Why is the first WCF client call slow?
  16. How to disable click sound in WebBrowser Control
  17. .NET DateTime.Now returns incorrect time when time zone is changed
  18. .Net Framework 4.6.1 not defaulting to TLS 1.2
  19. What does “{x:Static}” mean in XAML?
  20. How to make a .NET application “large address aware”?
  21. How do I improve ASP.NET MVC application performance?
  22. What does MethodImplOptions.Synchronized do?
  23. Equivalent of Class Loaders in .NET
  24. How to check an exchange mailbox via powershell?
  25. How do I fill an empty textbox with default text?
  26. Regex to match anything but two words
  27. Why are there two incompatible session state types in ASP.NET?
  28. How can I tell whether two .NET DLLs are the same?
  29. Why does BCL GZipStream (with StreamReader) not reliably detect Data Errors with CRC32?
  30. ‘Shadows’ vs. ‘Overrides’ in VB.NET

Leave a Comment