none
Does the Garbage Collector clean variables from the stack? RRS feed

  • Question

  • Hello, I was just curious if the Garbage collector cleaned variables from the stack?

     

    Thanks,

    Saied

    Monday, March 17, 2008 3:50 PM

Answers

  •  Saiedh wrote:

    Hello, I was just curious if the Garbage collector cleaned variables from the stack?

     

    Thanks,

    Saied



    The garbage collector, by it's very nature, only handles the managed Heap.
    The stack doesn't need clean up because it's reused automatically.

    When you enter a new function, a "stack frame" is constructed.  The stack pointer is simply moved forward to the first free location on the stack.
    When the function ends, the stack frame is destroyed simply by rewinding the stack pointer to it's last good location.  The data we "disposed" is still there, however unreachable it may be from a high level language perspective.

    When another new function is entered, the stack pointer again gets advanced "on top" of that stale data, and it's overwritten.

    You can think of it like this:

    Stack = [Application.Main's Frame]^
    Main() calls InitProgram().  Stack = [Application.Main's Frame][Application.InitProgram's frame]^
    InitProgram() returns.  Stack = [Application.Main]^[Application.InitProgram]

    Now, InitProgram's stack data still exists on the stack, but the stack pointer has been reversed to it's last good location.  The next time Main() makes a function call, InitProgram's stack will partially or wholey be overwritten with a new stack frame.

    This will continue ad infinitum as long as there's physical memory or page file space remaining.
    Monday, March 17, 2008 4:27 PM
  • No, the GC only looks at the managed heap. Anything that is placed on the stack and those allocations/deallocations are automatic.

    Monday, March 17, 2008 4:34 PM

All replies

  •  Saiedh wrote:

    Hello, I was just curious if the Garbage collector cleaned variables from the stack?

     

    Thanks,

    Saied



    The garbage collector, by it's very nature, only handles the managed Heap.
    The stack doesn't need clean up because it's reused automatically.

    When you enter a new function, a "stack frame" is constructed.  The stack pointer is simply moved forward to the first free location on the stack.
    When the function ends, the stack frame is destroyed simply by rewinding the stack pointer to it's last good location.  The data we "disposed" is still there, however unreachable it may be from a high level language perspective.

    When another new function is entered, the stack pointer again gets advanced "on top" of that stale data, and it's overwritten.

    You can think of it like this:

    Stack = [Application.Main's Frame]^
    Main() calls InitProgram().  Stack = [Application.Main's Frame][Application.InitProgram's frame]^
    InitProgram() returns.  Stack = [Application.Main]^[Application.InitProgram]

    Now, InitProgram's stack data still exists on the stack, but the stack pointer has been reversed to it's last good location.  The next time Main() makes a function call, InitProgram's stack will partially or wholey be overwritten with a new stack frame.

    This will continue ad infinitum as long as there's physical memory or page file space remaining.
    Monday, March 17, 2008 4:27 PM
  • No, the GC only looks at the managed heap. Anything that is placed on the stack and those allocations/deallocations are automatic.

    Monday, March 17, 2008 4:34 PM
  •  J Hallam wrote:

    When you enter a new function, a "stack frame" is constructed.  The stack pointer is simply moved forward to the first free location on the stack.
    When the function ends, the stack frame is destroyed simply by rewinding the stack pointer to it's last good location.  The data we "disposed" is still there, however unreachable it may be from a high level language perspective.


    It must be slightly more complicated than that; not saying that it uses the garbage collector, but at least the reference objects on the stack must have their Dispose methods called (for those which implement IDisposable) and their finalizers called, yes?
    Tuesday, March 18, 2008 3:18 AM
  •  omgtifbs wrote:
    It must be slightly more complicated than that; not saying that it uses the garbage collector, but at least the reference objects on the stack must have their Dispose methods called (for those which implement IDisposable) and their finalizers called, yes?

     

    Reference types are allocated on the heap.Only value types are stored on the stack and value types shouldn't implement IDisposable. If a value type does hold a disposable object, that object is allocated on the heap and the value type gets a pointer to it. When the value type is deallocated, the runtime stack memory management takes care of disposing the allocated object (this is somewhat simplified, but should get the point across).

    Tuesday, March 18, 2008 3:36 AM
  •  Scott Dorman wrote:

     omgtifbs wrote:
    It must be slightly more complicated than that; not saying that it uses the garbage collector, but at least the reference objects on the stack must have their Dispose methods called (for those which implement IDisposable) and their finalizers called, yes?

     

    Reference types are allocated on the heap.Only value types are stored on the stack and value types shouldn't implement IDisposable. If a value type does hold a disposable object, that object is allocated on the heap and the value type gets a pointer to it. When the value type is deallocated, the runtime stack memory management takes care of disposing the allocated object (this is somewhat simplified, but should get the point across).



    I understand now, thanks.  In terms of the original poster's question, it's pretty ambiguous then whether the GC deals with the stack.  It doesn't deal directly with the values on the stack, but it deals with the objects referenced in the stack.

    Since the stack will, in practice, contain lots of pointers to reference objects which were allocated as local variables within a method, the GC will be responsible for cleaning those up as soon as those pointers go out of scope.  Those references within the stack must be tracked by the GC just as any other references are.   The 'simple' process of reverting the stack frame upon a method's return, must alert the GC that all references within the old frame are no longer live.
    Tuesday, March 18, 2008 3:56 AM