DataGridViewRow not being Garbage Collected

I have a DataGridView being regularly populated via data-bound objects, and the number of rows can potentially become large, say many thousands during a 'logging cycle'.

When a new 'logging cycle' begins, the grid is cleared because the underlying datasource is cleared and the process begins again.

This is all fine, but because the previous run takes some time, all those previous rows have become Generation 2 objects, and only garbage collected on a full GC.

However, it takes TWO full GC's to clear them out because the first one sends them all to the finalizer queue. This means that they hang around twice as long hogging memory.

Using reflector, I see that DataGridViewRow does not have a finalizer method, but it does inherit from a DataGridViewBand object, which does - and it calls GC.SuppressFinalize(this) via it's public Dispose() method.

So my question is - why do my DataGridViewRows not get collected on the first full GC and make it onto the finalizer queue awaiting another one?

(My assumptions here are that any object without a finalizer should not get placed onto the finalizer queue, and any object that does have one but calls GC.SuppressFinalize will also not be placed on the queueo. Am I right in this assumption?)

Thanks.

Thanks Scott, so it appears my understanding is somewhat flawed? The fact that a row inherits from an object with a Finalize method means it will always be placed on the queue and subject to the double GC to clear it, and what I am seeing is correct? Ouch!

Andy 2009-10-07 19:37:55

@Andy: Yes, your understanding was incorrect. Since `DataGridViewRow` inherits from a finalizable object, it effectively becomes a finalizable object as well and is placed on the queue. What you are seeing is correct. Most likely the `Clear()` method does not also dispose of the rows, in which case you could manually dispose of them prior (or after) calling `Clear()` although I'm not certain if that will be possible. (It will depend on how things are implemented.) Optionally, you might be able to call `Dispose()` on the underlying datasource, which *might* work as well.

Scott Dorman 2009-10-07 19:42:46

Hmmm, interesting. I have tried calling Clear(), but I get errors because I 'Can't clear a databound grid', essentially because the databinding takes care of populating / depopulating which seems fair enough. Hadn't thought of calling dispose on the datasource though, will give it a go.

Andy 2009-10-07 19:48:47

Didn't appear to do anything, so I think it's the way it has to be.

Andy 2009-10-08 13:59:04

@Andy: I suspected that disposing the underlying datasource wouldn't have any effect, but it was worth checking just in case. The behavior you are seeing is very consistent with finalizable objects, particularly when there is no way to call `Dispose()` on them. Just one of the many reasons to avoid making objects finalizable unless there is a **very** good reason to do so.

Scott Dorman 2009-10-10 01:20:31

Interestingly, having done further tests, it appears that if I populate the list before binding it, the rows are GC'ed correctly when the list is unbound and cleared. It is only if I bind the list first, and then add to it that the problem arises. Unfortunately, this is what I want to do, to update the grid in real time, pffft.

Andy 2009-10-13 21:39:10

ansaurus

tags:

views:

answers:

DataGridViewRow not being Garbage Collected

related questions