locked
Collection of stuct object - does the GC will run ? RRS feed

  • Question

  • Hi,

     

    I have some collection that hold some struct.

    Its look like this :

     struct PointWithColor
    {
       Point p;
       Color c;
    
       public PointWithColor(Int32 x, Int32 y, Color c)
       {
         p = new Point( x, y );
         this.c = c;
        }
    };
    
    private List<PointWithColor> PointWithColorCollection = new List<PointWithColor>();
    

    My Question is .. .

    Because the object in the collection are value type - does this collection cleaning can cause somehow the GC to run ?

    If the answer is 'Yes' - is there some way to optimize this code and avoid GC to run ?

    Thanks.

    Tuesday, August 24, 2010 12:17 PM

Answers

  • 1) Yes: your generic list will be subject to the GC.

    You may have heard that value types get allocated onto the stack and that therefore they are not under control of the GC... while that is partially true, it confuses cause with effect. Value types are not allocated onto the stack because they are value types: they get sometimes allocated onto the stack because, thanks to their semantics, it is fairly easy for the compiler to determine when it's safe to do so.

    It is safe to allocate a local variable onto the stack when its lifetime cannot exceed that of the scope it was declared in. This is a necessary requirement, as when the stack frame gets popped, that variable will be lost. Since you cannot store a reference to some value type, it's relatively easy to understand why those end up on the stack.

    The members of your generic list are value types, but their lifetime is bound to that of the generic list itself; and since that is a reference type (and also a member field of some containing class) the aforementioned condition does not hold. So the whole list will be allocated onto the heap, along with its elements, and will be managed by the GC.

    2) No: you cannot avoid the GC (unless you use unmanaged memory)

    Anything that gets onto the heap MUST be managed by the GC. You still have the option to allocate some unmanaged memory and amuse yourself marshalling things in and out of there (or even just go unsafe and use pointers), but that's impractical, error prone, and may not provide more performance.

    HTH
    --mc

    • Proposed as answer by Amit_Ks Tuesday, August 24, 2010 1:10 PM
    • Marked as answer by Alan_chen Thursday, August 26, 2010 2:08 AM
    Tuesday, August 24, 2010 1:05 PM

All replies

  • 1) Yes: your generic list will be subject to the GC.

    You may have heard that value types get allocated onto the stack and that therefore they are not under control of the GC... while that is partially true, it confuses cause with effect. Value types are not allocated onto the stack because they are value types: they get sometimes allocated onto the stack because, thanks to their semantics, it is fairly easy for the compiler to determine when it's safe to do so.

    It is safe to allocate a local variable onto the stack when its lifetime cannot exceed that of the scope it was declared in. This is a necessary requirement, as when the stack frame gets popped, that variable will be lost. Since you cannot store a reference to some value type, it's relatively easy to understand why those end up on the stack.

    The members of your generic list are value types, but their lifetime is bound to that of the generic list itself; and since that is a reference type (and also a member field of some containing class) the aforementioned condition does not hold. So the whole list will be allocated onto the heap, along with its elements, and will be managed by the GC.

    2) No: you cannot avoid the GC (unless you use unmanaged memory)

    Anything that gets onto the heap MUST be managed by the GC. You still have the option to allocate some unmanaged memory and amuse yourself marshalling things in and out of there (or even just go unsafe and use pointers), but that's impractical, error prone, and may not provide more performance.

    HTH
    --mc

    • Proposed as answer by Amit_Ks Tuesday, August 24, 2010 1:10 PM
    • Marked as answer by Alan_chen Thursday, August 26, 2010 2:08 AM
    Tuesday, August 24, 2010 1:05 PM
  • Do not understand fully your point but in general you can create your own way of disposing object if you do not want the gc to do it for you.

    In some cases this is desired because of unmanaged code (your own responsability) or you can do better than the gc.

    The gc will run at some point, not when your object goes out of scope, you can force it to run and promote objects for disposing.

    In 90% of the cases letting the gc do the work is better.

    Regards

    Tuesday, August 24, 2010 1:08 PM