1

Today, I have read a blog on CodeProject about Memory management .NET.

URL - Article

It says -

Exiting the method (the fun): Now finally the execution control starts exiting the method. When it passes the end control, it clears all the memory variables which are assigned on stack. In other words all variables which are related to int data type are de-allocated in ‘LIFO’ fashion from the stack.

The big catch – It did not de-allocate the heap memory. This memory will be later de-allocated by the garbage collector.

As per my understanding, Garbage collector only de-allocate the Heap memory. So, who will de-allocate the stack memory?

Please suggest.

trincot
  • 317,000
  • 35
  • 244
  • 286
KiddoDeveloper
  • 568
  • 2
  • 11
  • 34
  • By default, the callee is responsible for cleaning the stack (`stdcall` calling convention). – Frédéric Hamidi Sep 13 '16 at 08:47
  • 2
    [What and where are Stack and Heap](http://stackoverflow.com/q/79923/69809). – vgru Sep 13 '16 at 08:53
  • 2
    Codeproject.com content is not subject to any kind of decent review. Lots of nonsense and bugs because of that, including the first paragraph of this quote. Nothing is "cleared" or "deallocated", local variables are simple forgotten when the method returns. Not unlike the way the .NET Stack<> class works btw. – Hans Passant Sep 13 '16 at 08:54

3 Answers3

2

Values on the stack are automatically managed even without garbage collection because items are added and removed from the stack in a LIFO fashion every time you enter/exit a scope (be it a method or a statement), which is precisely why variables defined within a for loop or if statement aren’t available outside that scope.

You will receive a StackOverflowException when you’ve used up all the available space on the stack, though it’s almost certainly the symptom of an infinite loop (bug!) or poorly designed system which involves near-endless recursive calls.

Debendra Dash
  • 5,334
  • 46
  • 38
0

In short:

The stackmemory isn't deallocated. It's one block of memory that will be reused. Each time a scope declared variables (pushed onto the stack), it will be popped when the scope exits.

So when a method is called, the parameters (a value or a reference pointer) are pushed (copied) onto the stack and popped from it, when the method ends. (popping is just adjusting a pointer (index) with the memory)

That's why variables declared within the { } aren't available behind de }

This chunk of memory is per thread.

Jeroen van Langen
  • 21,446
  • 3
  • 42
  • 57
0

In .NET, a variable is located on the stack, regardless of whether it holds a number (a value type), a struct (located entirely on the stack), or a reference to an object (i.e. the managed address of the object, where the object itself is located on the heap).

Also, people sometimes confuse variables with class fields. Fields, and all class members, are located on the heap, inside the area allocated when the object was instantiated.

So, there are no allocations or deallocations of any variables, since they are just values which go out of scope. After the variable goes out of scope, the GC cannot reach the actual (heap) object and it collects it eventually.

vgru
  • 49,838
  • 16
  • 120
  • 201
  • Scope is not relevant. The GC can also collect objects that are referenced by local variables when the method has not exited yet. It can even collect *this* in an instance method. Ensuring that this doesn't cause any trouble is a [primary job of the jitter](http://stackoverflow.com/a/17131389/17034). – Hans Passant Sep 13 '16 at 09:15
  • That's true, GC is optimized to collect the object instance as soon as it realizes the variable is not used anymore, even if it still hasn't gone out of its scope. But OP's question was about stack "deallocation", and I doubt there is a CLR implementation in which the stack pointer gets moved anywhere before the variable really gets out of scope. Anyway, your comment is indeed more precise. – vgru Sep 13 '16 at 09:29