1

Scenario

  • Lets say that I've decided I really need to call GC.Collect();
  • What do I need to do to ensure that an object is prepared to be garbage collected appropriately before I actually call this method?
  • Would assigning null to all properties of the object be enough? Or just assigning null to the object itself?

If you really need to know why.....

  • I have a distributed application in WCF that sends a DataContract over the wire every few seconds, containing 8 Dictionaries as DataMembers.
  • This is a lot of data and when it comes into the Client-side interface, a whole new DataContract object is created and the memory usage of the application is growing so big that I'm getting OutOfMemory Exceptions.

Thanks

EDIT

Thanks for all the comments and answers, it seems that everyone shares the same opinion.

  • What I cannot understand is how I can possibly dispose correctly because the connection is open constantly.
  • Once I've copied the data over from the incoming object, I don't need the object anymore, so would simply implementing IDisposable on that DataContract object be enough?
  • My original problem is here - Distributed OutOfMemory Exceptions
Community
  • 1
  • 1
Goober
  • 13,146
  • 50
  • 126
  • 195
  • 3
    "I'm getting OutOfMemory Exceptions" - the garbage collector is designed to kick in automatically before this point. If it's not, then you're probably holding onto some reference longer than you need to. – Tim Robinson Nov 10 '10 at 11:23
  • How do I know I'm holding onto a reference? – Goober Nov 10 '10 at 11:42
  • because it isn't being collected (which sounds a bit chicken / egg, I admit) – Marc Gravell Nov 10 '10 at 12:28

6 Answers6

3

As long as nothing else can see the object it is already eligible for collection; nothing more is required. The key point here is to ensure that nothing else is watching it (or at least, nothing with a longer lifetime):

  • is it in a field somewhere?
  • is it in a variable in a method that is incomplete? (an infinite loop or iterator block, perhaps)
  • is it in a collection somewhere?
  • has it subscribed to some event?
  • it is captured in a closure (lambda / anon-method) that is still alive?

I genuinely doubt that GC.Collect() is the answer here; if it was eligible it would have already been collected. If it isn't elgible, calling GC.Collect() certainly won't help and quite possibly will make things worse (by tying up CPU when nothing useful can be collected).

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • The real problem with calling GC.Collect explicitly is that is pushes objects into later generations, meaning you are actually delaying their collection. – snarf Nov 10 '10 at 12:09
  • The GC is *already tuned out of the box*. If you collect more frequently than you need to (i.e. explicitly) you will push objects to higher generations faster. The more often you collect, the lower the number of objects that will be eligible for collection, the higher the number of objects that get unwarranted promotions. It is rare that you'll be able to outsmart the GC. I would love to have a GC.CollectButDontPromote method, but since it isn't there, unless profiling tells you your explicit collects are helping, I'd say don't do it. – snarf Nov 10 '10 at 22:01
2

You don't generally need to do anything.

If the object is no longer referenced then it's a candidate for collection. (And, conversely, if the object is still referenced then it's not a candidate for collection, however you "prepare" it.)

LukeH
  • 263,068
  • 57
  • 365
  • 409
1

You need to clean up any unmanaged resources like database connections etc.
Typically by implementing IDisposable and call Dispose.

If you have a finalizer you should call GC.SuppressFinilize.

The rest is cleaned up by the garbage collector.

Edit:
And, oh, naturally you need to release all references to your object.

But, and here is this big but. Unless you have a very very special case you don't need to call GC.Collect. You probably forgets to release some resources or references, and GC.Collect won't help you with that. Make sure you call Dispose on everything Disposable (preferably with the using-pattern).

You should probably pick up a memory profiler like Ants memory profiler and look where all your memory has gone.

Albin Sunnanbo
  • 46,430
  • 8
  • 69
  • 108
  • Once I've copied the data over from the incoming object, I don't need the object anymore, so would simply implementing IDisposable on that DataContract object be enough? – Goober Nov 10 '10 at 12:02
  • @Goober No. The type with the DataContract does not contain any managed resources, you don't need to implement IDisposable then. It will be up for GC collection once you leave the method with OperationContract unless you have stored it somewhere else. – Albin Sunnanbo Nov 10 '10 at 12:27
  • @Goober Try the Ants memory profiler, you can try it for free for 30 days or so. It will help you determine what objects that stays in memory and where they still are referenced. – Albin Sunnanbo Nov 10 '10 at 12:28
  • @Goober, Not nessecarily. IDisposable can only get rid of references the object itself controls, if its subscribed to events, it can ask to be unsubscribed, but if the object with the event hasn't implemented its remove properly, it may still hold a reference to you. Also, lambdas can be a source of frustration. 2 things can help, WINDBG can tell you whats holding references to what. Reactive Extentions can be used to reverse code that uses collections, and results in less housekeeping code... – stevenrcfox Nov 10 '10 at 12:50
  • Turned out to be something really stupid, which I found thanks to ANTS Memory Profiler. Much appreciated. – Goober Nov 10 '10 at 14:55
1

If you have no more direct reference to an object, and you're running out of memory, GC should do this automatically. Do make sure you call .Dispose() on your datacontext.

Joachim VR
  • 2,320
  • 1
  • 15
  • 24
1

Calling GC.Collect will hardly ever prevent you from getting OutOfMemory exceptions, because .NET will call GC.Collect itself when it is unable to create a new object due to OOM. There is only one scenario where I can think of and that is when you have unreferenced objects that are registered in the finalizable queue. When these objects reference many other objects it can cause a OOM. The solution to this problem is actually not to call GC.Collect but to ensure that those objects are disposed correctly (and implement the dispose pattern correctly when you created those objects).

Steven
  • 166,672
  • 24
  • 332
  • 435
1

Using GC.Collect in general

Since you are trying to get rid of a very large collection, it's totally valid to use GC.Collect(). From the Microsoft docs:

... since your application knows more about its behavior than the runtime does, you could help matters by explicitly forcing some collections. For example, it might make sense for your application to force a full collection of all generations after the user saves his data file.

"Preparing" your objects

From the excellent Performance Considerations for Run-Time Technologies in the .NET Framework (from MSDN):

If you keep a pointer to a resource around, the GC has no way of knowing if you intend to use it in the future. What this means is that all of the rules you've used in native code for explicitly freeing objects still apply, but most of the time the GC will handle everything for you.

So, to ensure it's ready for GC, Make sure that you have no references to the objects you wish to collect (e.g. in collections, events, etc...). Setting the variable to null will mean it's ready for collection before the variable goes out of scope.

Also any object which implements IDisposable should have it's Dispose() method called to clean up unmanaged resources.

Before you use GC.Collect

Since it looks like your application is a server, using the Server GC may resolve your issue. It will likely run more often and be more performant in a multi-processor scenario.

The server GC is designed for maximum throughput, and scales with very high performance.

See the Choosing Which Garbage Collector to Use within Performance Considerations for Run-Time Technologies in the .NET Framework (from MSDN):

badbod99
  • 7,429
  • 2
  • 32
  • 31