C# Clearing list before nulling

Question

Today I have seen a piece of code that first seemed odd to me at first glance and made me reconsider. Here is a shortened version of the code:

if(list != null){
    list.Clear();
    list = null;
}

My thought was, why not replace it simply by:

list = null;

I read a bit and I understand that clearing a list will remove the reference to the objects allowing the GC to do it's thing but will not "resize". The allocated memory for this list stays the same.

On the other side, setting to null would also remove the reference to the list (and thus to its items) also allowing the GC to do it's thing.

So I have been trying to figure out a reason to do it the like the first block. One scenario I thought of is if you have two references to the list. The first block would clear the items in the list so even if the second reference remains, the GC can still clear the memory allocated for the items.

Nonetheless, I feel like there's something weird about this so I would like to know if the scenario I mentioned makes sense?

Also, are there any other scenarios where we would have to Clear() a list right before setting the reference to null?

Finally, if the scenario I mentioned made sense, wouldn't it be better off to just make sure we don't hold multiple references to this list at once and how would we do that (explicitly)?

Edit: I get the difference between Clearing and Nulling the list. I'm mostly curious to know if there is something inside the GC that would make it so that there would be a reason to Clear before Nulling.

Answer 1

The list.Clear() is not necessary in your scenario (where the List is private and only used within the class).

A great intro level link on reachability / live objects is http://levibotelho.com/development/how-does-the-garbage-collector-work :

How does the garbage collector identify garbage?

In Microsoft’s implementation of the .NET framework the garbage collector determines if an object is garbage by examining the reference type variables pointing to it. In the context of the garbage collector, reference type variables are known as “roots”. Examples of roots include:

• A reference on the stack
• A reference in a static variable
• A reference in another object on the managed heap that is not eligible for garbage collection
• A reference in the form of a local variable in a method

The key bit in this context is A reference in another object on the managed heap that is not eligible for garbage collection. Thus, if the List is eligible to be collected (and the objects within the list aren't referenced elsewhere) then those objects in the List are also eligible to be collected.

In other words, the GC will realise that list and its contents are unreachable in the same pass.

So, is there an instance where list.Clear() would be useful? Yes. It might be useful if you have two references to a single List (e.g. as two fields in two different objects). One of those references may wish to clear the list in a way that the other reference is also impacted - in which list.Clear() is perfect.

Answer 2

This answer started as a comment for Mick, who claims that:

It depends on which version of .NET you are working with. On mobile platforms like Xamarin or mono, you may find that the garbage collector needs this kind of help in order to do its work.

That statement is begging to be fact checked. So, let us see...

---

.NET

.NET uses a generational mark and sweep garbage collector. You can see the abstract of the algorithm in What happens during a garbage collection . For summary, it goes over the object graph, and if it cannot reach a object, that one can be erased.

Thus, the garbage collector will correctly identify the items of the list as collectible in the same iteration, regardless of whatever or not you clear the list. There is no need to decouple the objects beforehand.

This means that clearing the list does not help the garbage collector on the regular implementation of .NET.

Note: If there were another reference to the list, then the fact that you cleared the list would be visible.

---

Mono and Xamarin

Mono

As it turns out, the same is true for Mono.

Xamarin.Android

Also true for Xamarin.Android.

Xamarin.iOS

However, Xamarin.iOS requires additional considerations. In particular, MonoTouch will use wrapped Objective-C objects which are beyond the garbage collector. See Avoid strong circular references under iOS Performance. These objects require different semantics.

Xamarin.iOS will minimize the use of Objetive-C objects by keeping a cache:

C# NSObjects are also created on demand when you invoke a method or a property that returns an NSObject. At this point, the runtime will look into an object cache and determine whether a given Objective-C NSObject has already been surfaced to the managed world or not. If the object has been surfaced, the existing object will be returned, otherwise a constructor that takes an IntPtr as a parameter is invoked to construct the object.

The system keeps these objects alive even there are no references from managed code:

User-subclasses of NSObjects often contain C# state so whenever the Objective-C runtime performs a "retain" operation on one of these objects, the runtime creates a GCHandle that keeps the managed object alive, even if there are no C# visible references to the object. This simplifies bookeeping a lot, since the state will be preserved automatically for you.

Emphasis mine.

Thus, under Xamarin.iOS, if there were a chance that the list might contain wrapped Objetive-C objects, this code would help the garbage collector.

See the question How does memory management works on Xamarin.IOS, Miguel de Icaza explains in his answer that the semantics are to "retain" the object when you take a reference and "release" it when the reference is null.

On the Objetive-C side, "release" does not mean to destroy the object. Objetive-C uses a reference count garbage collector. When we "retain" the object the counter is incremented and when we "release" the counter is decreased. The system destroys the object when the counter reaches zero. See: About Memory Management.

Therefore, Objetive-C is bad at handling circular references (if A references B and B references A, their reference count is not zero, even if they cannot be reached), thus, you should avoid them in Xamarin.iOS. In fact, forgetting to decouple references will lead to leaks in Xamarin.iOS... See: Xamarin iOS memory leaks everywhere.

---

Others

dotGNU also uses a generational mark and sweep garbage collector.

I also had a look at CrossNet (that compiles IL to C++), it appears they attempted to implement it too. I do not know how good it is.