none
Call List<T>.Clear helpful to GC? or set to null? RRS feed

  • Question

  • static void Main(string[] args)
    {
          List<object> tests = new List<object>(){ new object()};
          WeakReference wr = new WeakReference(tests[0]);
          tests.Clear(); // when disabled, the result is different, WHY?
          tests = null;
          GC.Collect();
          Console.WriteLine(wr.IsAlive.ToString());
          Console.ReadKey();
    }


    • Edited by Henry Ho Tuesday, June 28, 2011 11:12 AM
    Tuesday, June 28, 2011 9:44 AM

Answers

  • Hi Henry,

    If you look at the code henry it has nothing to do with List<T> actually , the weakrefernce is holding the reference of new object that you have initialised in the constructor. 

    When you call tests.clear() you are letting of the reference of that object hence wr.IsAlive returns false. When you dont clear it but set the test to null, the previous reference is still holding on the object hence wr.IsAlive returns true.

     

    Hope this satisfies your question


    Pratap --Mark the best replies as answers!
    • Marked as answer by Henry Ho Wednesday, June 29, 2011 6:43 AM
    Tuesday, June 28, 2011 5:27 PM

All replies

  • Hi

    This is probably 

    When you call tests.Clear() Clears  object reference to particular collection , so this object is collected by GC

    When you set tests = null , it de-references tests to real object collection in memory.

     

    one more observation 

    it is enough to call tests.Clear() objects to be collected by GC.


    If this post answers your question, please click "Mark As Answer". If this post is helpful please click "Mark as Helpful".
    Tuesday, June 28, 2011 10:41 AM
  • Hi

    This is probably 

    When you call tests.Clear() Clears  object reference to particular collection , so this object is collected by GC

    When you set tests = null , it de-references tests to real object collection in memory.

     

    one more observation 

    it is enough to call tests.Clear() objects to be collected by GC.


    If this post answers your question, please click "Mark As Answer". If this post is helpful please click "Mark as Helpful".


    As far as i know, Mark & Compact algorithms collect items of List when "tests == null",

    so, clear() is not necessary. but the test result is NO. why?


    Tuesday, June 28, 2011 11:06 AM
  • From your code the memory layout of your tests would be something like this

    tests 

    -- > obj1

    -- > obj2 

    When you are calling tests.clear() the references of these objects are removed from the list but not the list itself.

    After tests.Clear().Count() would yield 0, but after tests==null it would yield a null reference exception


    Pratap --Mark the best replies as answers!
    Tuesday, June 28, 2011 11:48 AM
  • From your code the memory layout of your tests would be something like this

    tests 

    -- > obj1

    -- > obj2 

    When you are calling tests.clear() the references of these objects are removed from the list but not the list itself.

    After tests.Clear().Count() would yield 0, but after tests==null it would yield a null reference exception


    Pratap --Mark the best replies as answers!

    List<T> maintain an inner array, Clear() just set counter to 0.

    SO:

    (1) tests.Clear(); tests = null;

    (2) tests = null;

    (1) & (2) is same thing to GC, what's the wrong with me?


    Tuesday, June 28, 2011 12:28 PM
  • Hi Henry,

    If you look at the code henry it has nothing to do with List<T> actually , the weakrefernce is holding the reference of new object that you have initialised in the constructor. 

    When you call tests.clear() you are letting of the reference of that object hence wr.IsAlive returns false. When you dont clear it but set the test to null, the previous reference is still holding on the object hence wr.IsAlive returns true.

     

    Hope this satisfies your question


    Pratap --Mark the best replies as answers!
    • Marked as answer by Henry Ho Wednesday, June 29, 2011 6:43 AM
    Tuesday, June 28, 2011 5:27 PM