cbrumme s WebLog Turning off the garbage collector | Insomnia Cure

cbrumme s WebLog Turning off the garbage collector | Insomnia Cure — Sat, 13 Jun 2009 10:00:38 GMT

PingBack from http://insomniacuresite.info/story.php?id=9170

Memory Not Being Claimed | keyongtech

Memory Not Being Claimed | keyongtech — Thu, 22 Jan 2009 04:25:20 GMT

PingBack from http://www.keyongtech.com/2390869-memory-not-being-claimed

Even more on IDisposable

TheChaseMan's Frenetic SoapBox — Wed, 16 Mar 2005 23:08:00 GMT

A Few Good GC Links

Chris Lyon's WebLog — Tue, 14 Sep 2004 21:40:00 GMT

re: Turning off the garbage collector

Chris Brumme — Wed, 14 Apr 2004 18:26:00 GMT

Explicitly collecting is generally a bad idea. Promotion of short-lived objects into older generations is indeed one of the problems this will cause.

re: Turning off the garbage collector

David Goldstein — Wed, 14 Apr 2004 17:25:00 GMT

This was a debate I started at Code Project...
if you explicitly collect, won't you artificially promote short-lived gen0 objects into further generations?

davegoldstein@nospam.adelphia.net

RE: Turning off the garbage collector

Chris Brumme — Mon, 05 May 2003 20:04:00 GMT

Within Microsoft, I occasionally run into teams who are triggering the garbage collector so they can recover a particular instance. This is a bad idea. The GC’s purpose is to efficiently manage resources. Because of this, GC.Collect & GC.WaitForPendingFinalizers are non-deterministic. The way to achieve determinism in an application is through IDisposable and similar APIs, not by jiggling the GC. One can never predict when the last reference to an object has been released. Storing a reference to null might be eliminated by the JIT as a dead store. Depending on register allocation, the lifetime of your reference might be extended to the end of a method. Depending on how aggressively the JIT is inlining, the lifetime of your reference might be extended to the end of some enclosing method. We should not confuse the lifetime of an object’s memory with the semantics we try to achieve inside a Finalize method. And we should never trigger expensive GCs and draining of the finalizer queue when we are trying to have an impact on a particular object. So what is a legitimate use of GC.Collect and GC.WaitForPendingFinalizers? It is to have a statistical effect on the state of the GC heap. If you have closed a bunch of windows, or finished a long-running request, or released a ton of cached objects, then calling GC.Collect() might make good sense from a statistical point of view. But there are no guarantees on whether a particular object will collect. Along the same lines, a HandleCollector might track the number of outstanding instances of a scarce resource. If a client requests a new instance and some threshold has been reached, the HandleCollector can trigger a GC and WaitForPendingFinalizers – hoping to reclaim some resources. But it isn’t making these calls with a goal of reclaiming a particular instance. If you rely on GC.Collect / WaitForPendingFinalizers to recover a particular instance, your app will certainly be broken as we pursue more aggressive code generation and GC techniques. (Or perhaps it will just be broken during debugging, or when you run on a non-X86 CPU, or even a machine with more memory).