How objects (reference types- heap) communicate with variables stored on stack

as we know reference types are always stored on heap and value types are in stack memory.

e.g.

public Class A{
  public int myInt=10;
  public void Display(){
  }
}

here, if i create object of class A it goes in heap and myInt goes in stack r开发者_JAVA百科ight..?

now, how class object (heap) interact with myInt public variable (stack)?

can anybody please explain it..

I'm afraid your assumption is wrong if you're talking about .NET. Value types are only stored on the stack when they are not part of an instance of a reference type. I.e. your myInt is stored as part of any instance of A on the heap.

as we know reference types are always stored in heap

Ask yourself: which part of the reference type is stored on the heap? What kind of memory? What does the reference type consist of?

– Primarily, it consists of the memory of its member variables.¹⁾ These are the data that is stored on the heap. So in your example, that would be the myInt variable.

Value types are only stored on the stack (as you assumed) if they are local variables inside a method, or their parameters. This is what the stack is there for: storing local variables and parameters (and the return pointers of function calls).

¹⁾ And also sometimes a so-called vtable which stores the addresses of virtual functions. But this is irrelevant for this question.

Generally, locating variables is compilers task.

If you create an instance of class A, say A obj=new A(); an object of type A is created on the heap. This object on the heap constitutes of the instance varialbe myInt also on the heap along with other member variables, if there were any. And you are referring to this object on the heap with a reference variable obj which will be on the stack. For example,

class Mainclass{
main(){
A obj=new A();
//......all other code......
}
}

EDIT:

Must-read for .net developers:
Memory in .Net and Reference and values.

I'll do all my talking w.r.t. C# language:

Quoting you:

as we know reference types are always stored on heap and value types are in stack memory.

TL;DR; This is not true. Please read the details I've posted below. In your case, the object instance of class A and the myInt member variable both will get stored on heap irrespective of the fact that myInt is a value type.

To Summarize how variables are stored on heap and stack::

The stack is always used to store the following two things:

• The reference portion of reference-typed local variables in the functions and their parameters.
• Value-typed local variables and method parameters (structs, as well as integ$ers, bools, chars, DateTimes, etc.)

The following data is stored on the heap:

• The content of reference-type objects.
• Anything structured inside a reference-type object.

E.g.

Main()
{
MyClass obj = new MyClass();
}

Class MyClass
{
   int32 i;
   Dataset dst;

   private void MyMethod(int32 j, dataset dst2)
   {
           int32 k;
           Dataset dst3;
   }

Here are the memory allocation details:

1. obj which is a object reference - Stack
2. Instance of Myclass to which obj variable is pointing - Managed Heap
3. Value type Member variable i - Managed Heap
4. dst which is a dataset object reference - Managed Heap
5. Instance of dataset to which dst variable is pointing - Managed Heap
6. Value type parameter j - Stack
7. dst2 which is a dataset object reference - Stack
8. Instance of dataset to which dst2 variable is pointing - Managed Heap
9. Value type Local variable k - Stack
10. dst3 which is a dataset object reference - Stack
11. Instance of dataset to which dst3 is pointing - Managed heap

I think I've covered all permutations and combination.

Quoting you again:

now, how class object (heap) interact with myInt public variable (stack)?

First thing that I want to add here is that object and variables don't interact. It is code (executable IL instructions present in a method) which interact with public variables of a class instance (aka object).

See, CLR loads a type only once in memory. So all the IL instructions corresponding to your Display method will be located centrally in memory irrespective of the number of instances of class A that you create in your program. Only the instances (containing member variable data) of class A will occupy different place (memory address to be precise) in heap.

So whenever the IL instruction for Display method is getting executed it has a pointer to this which is a reference to the current object instance in heap. this reference is different for different object instances. this always points to the starting memory address layout of your current object instance. From there on an offset is required to reach to the memory address where myInt is located to access/change it.

I hope this will help you make a mental model of how C# code runs under the hood in CLR environment.