Posted on


Despite the fact that with the .NET structure we don’t need to effectively stress over memory administration and trash accumulation (GC), regardless we need to remember memory administration and GC to improve the execution of our applications. Likewise, having a fundamental comprehension of how memory administration functions will clarify the conduct of the variables we work with in each system we compose. In this article I’ll cover the fundamentals of the Stack and Heap, sorts of variables and why a few variables fill in as they do. There are two places the .NET system stores things in memory as your code executes. On the off chance that you are not yet acquainted with them, let me acquaint you with the Stack and the Heap. Both the Stack and Heap offer us some assistance with running our code. They live in the working memory on our machine and contain the bits of data we have to make everything happen.

Stack vs. Heap: What’s the difference?

The Stack is pretty much in charge of monitoring what’s executing in our code (or what’s been “called”). The Heap is pretty much in charge of monitoring our items.

Think about the Stack as a progression of boxes stacked one on top of the following. We monitor what’s stacking so as to happen in our application another box on top each time we call a system (called a Frame). We can just utilize what’s in the top box on the Stack. When we’re finished with the top box (the strategy is done executing) we discard it and continue to utilize the stuff in the past box on the highest point of the Stack. The Heap is comparable with the exception of that its motivation is to hold data (not monitor execution more often than not) so anything in our Heap can be gotten to whenever. With the Heap, there are no limitations concerning what can be gotten to like in the Stack. The Heap is similar to the store of clean clothing on our bed that we have not taken an ideal opportunity to secure yet; we can snatch what we require rapidly. The Stack is similar to the Stack of shoe boxes in the storeroom where we need to remove the main one to get to the one underneath the Stack is self-keeping up, implying that it essentially deals with its own memory administration. At the point when the top box is no more utilized, it’s tossed out. The Heap, then again, should stress over Garbage accumulation (GC), which manages how to keep the Heap clean (nobody needs filthy clothing laying around, it stinks!). We have four main types of things we’ll be putting in the Stack and Heap as our code is executing: Value Types,Reference Types, Pointers, and Instructions.

Value Types:

  1.  bool
  2.  byte
  3.  char
  4.  decimal
  5.  double
  6.  enum
  7.  float
  8.  int
  9.  long
  10.  sbyte
  11.  short
  12.  struct
  13.  uint
  14.  ulong
  15.  ushort

Reference Types:

  1.  class
  2.  interface
  3.  delegate
  4.  object
  5.  string


The third sort of “thing” to be placed in our memory administration plan is a Reference to a Type. A Reference is frequently alluded to as a Pointer. We don’t expressly utilize Pointers, they are overseen by the Common Language Runtime (CLR). A Pointer (or Reference) is not the same as a Reference Type in that when we say something is a Reference Type, it implies we get to it through a Pointer. A Pointer is a piece of space in memory that indicates another space in memory. A Pointer consumes up room simply like some other thing that we’re putting in the Stack and Heap and its quality is either a memory address or invalid.

How is it chosen what goes where?

Here are our two golden rules:

A Reference Type always goes on the Heap; easy enough, right?

Value Types and Pointers always go where they were declared. This is a little more complex and needs a bit more understanding of how the Stack works to figure out where “things” are declared.

The Stack, as we mentioned earlier, is responsible for keeping track of where each thread is during the execution of our code (or what’s been called).  You can think of it as a thread “state” and each thread has its own Stack.  When our code makes a call to execute a method the thread starts executing the instructions that have been JIT compiled and live on the method table, it also puts the method’s parameters on the thread Stack. Then, as we go through the code and run into variables within the method, they are placed on top of the Stack. Once our system achieves a specific memory limit and we require more Heap space, our GC will commence. The GC will stop every single running string (a FULL STOP), discover all articles in the Heap that are not being gotten to by the primary program and erase them. The GC will then redesign every one of the articles left in the Heap to make space and change every one of the Pointers to these items in both the Stack and the Heap. As you can envision, this can be entirely costly regarding execution, so now you can see why it can be critical to pay consideration on what’s in the Stack and Heap when attempting to compose superior code.

public void Method1()


// Line 1

int i=4;

// Line 2

int y=2;

//Line 3

class1 cls1 = new class1();


It’s a three line code, how about we comprehend line by line how things execute inside.

Line 1: When this line is executed, the compiler distributes a little measure of memory in the stack. The stack is in charge of monitoring the running memory required in your application.

Line 2: Now the execution moves to the following step. As the name says stack, it stacks this memory designation on top of the first memory allotment. You can consider stack as a progression of compartments or boxes put on top of one another. Memory designation and de-allotment is done utilizing LIFO (Last In First Out) rationale. At the end of the day memory is allotted and de-assigned at stand out end of the memory, i.e., top of the stack.

Line 3: In line 3, we have made an article. At the point when this line is executed it makes a pointer on the stack and the real protest is put away in an alternate sort of memory area called ‘Load’. “Pile” does not track running memory, it’s only a heap of articles which can be come to at any snippet of time. Stack is utilized for element memory assignment. One more imperative point to note here is reference pointers are dispensed on stack. The announcement, Class1 cls1; does not allot memory for an occurrence of Class1, it just dispenses a stack variable cls1 (and sets it to invalid). The time it hits the new catchphrase, it distributes on “load”. Leaving the strategy (the fun): Now at long last the execution control begins leaving the system. When it passes the end control, it clears all the memory variables which are alloted on stack. As it were all variables which are identified with int information sort are de-dispensed in “LIFO” design from the stack.

In the event that you look carefully, primitive information sorts are not complex, they hold single qualities like ‘int i = 0’. Object information sorts are perplexing, they reference different items or other primitive information sorts. At the end of the day, they hold reference to other numerous qualities and every one of them must be put away in memory. Object sorts need dynamic memory while primitive ones needs static sort memory. In the event that the necessity is of element memory, it’s dispensed on the load or else it goes on a stack.


For more details and queries please feel free to email, visit or call us. Wishing you the very best for all your future endeavors.
Helpline: 9814666333, 8699444666
Email: info@technocampus.co.in

Please fill the form and we shall contact you soon.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s