title: Does the Code Block of a method live in the stack or heap at the moment of execution?
body: <p>I'm relatively new to learning programming languages, and I feel I have 20 to 25% of understanding of Object Oriented Programming Language, more specifically C# language. So I really state this question without knowing the actual significance of its answer, if any, to my process of learning the language, but I really felt I need to ask it.</p>
  
  <p>When a method is called for execution, I know that all its local variables and its parameters and return value are actually present in the stack memory. While the method itself is called from the heap memory as a member of  an instantiated object or a static class, or as a static member of a of a non static class.</p>
  
  <p>Now my question here is, when the method is called into the stack, is it only the variables and parameters that are going to exist in the stack, or is it the whole method with all its code block will be existing in the stack at that moment ( of execution )?</p>
  
  <p>This query has arisen from the analogous comparison of nature of the code block inside an instantiated method ( or a static method ), while the method is being called and while it isn't being called, when compared to the nature of the members of a non static class while the class is instantiated into an object, and while not.</p>
  
  <p>Now, the members of a nonstatic class, are thought of like a blue print, i.e. they are existing in a form that is non-approachable and non-functional ( fields and methods cannot be called, and the values of fields cannot get changed, the methods cannot change values ), but this blueprint is rather instantiable into a concrete functioning object with its members.</p>
  
  <p>Now if the code block inside an instantiated method in the heap is nothing but a blueprint, a blueprint that will practically get "instantiated" in the stack when the method is being called, to perform the task their in the stack, then get deleted off the stack when the task is accomplished. Here the stack can be seen as the place of actual execution of the program, while on the other hand everything in the heap including the static classes and the objects and the heap itself will be seen as a mere storage place for data and instructions for the stack to borrow and utilise every now and then, the stack actually performs the tasks of our whole program.</p>
  
  <p>If, however, the stack memory doesn't actually contain the code of a method that is getting executed, and the stack only takes the temporary values of the method's local variables and parameters, while the method itself in the heap and concurrently performing the coded instructions from its heap position, loaning only the values to the stack in the process. Here the stack will look like a mere variable's value holder, while the object and static classes with their methods are the actual performers of the program their in the heap itself, and an instantiated method ( or a static one ) with its code is concretely present and functioning in the heap.</p>
  
  <p>A third possibility is that neither of the two memories ( stack and heap ) are the actual place of code execution, rather somewhere in the processor itself that the execution and changing of data is taking place, with both the heap and stack being mere storage places for different patterns of utilisation in terms of accepting, preserving, and cleaning data and instructions, and that's it.</p>
  
  <p>I'm sorry for such a long question, I don't know how helpful to gain its answer for me as a programmer, but it really caused me a headache for couple of days and I couldn't find an answer in the text that are designed for beginners so I got really overwhelmed!</p>