Is there an advanced article which I can read that can explain how memory is allocated for different types (value and reference) in .net framework.
for example we kn
Remember the rule, Reference types always goes to the Heap, whereas Value Types always go where they were declared. If a Value Type is declared outside of a method, but inside a Reference Type it will be placed within the Reference Type on the Heap.
This article seems advanced without going overboard. It should provide you with a much better understanding:
http://www.simple-talk.com/dotnet/.net-framework/understanding-garbage-collection-in-.net/
When a method is called the amount of space required by value types is known in advance (it can be computed by the compiler). This space is allocated on the stack and is only available for the duration of the method call. For each new method call the memory used on the stack grows and when the method exits it shrinks back to it's previous level.
Reference types are allocated on the heap. The heap is basically a block of memory used for that purpose. An object stored on the heap is primarily the fields of the object stored in the the memory allocated to the object. Thus value type fields are stored "inside" the object on the heap. Reference type fields are stored as a reference (or pointer) to the referenced object. The memory on the heap are managed by garbage collection. It is a complex subject but the short story is that memory allocated to unused objects on the heap are freed and thus eligble for reuse at regular intervals by the garbage collector.
A value type is "allocated" where it is defined.
What that means depends on where you define it:
A reference type is sort of a dual value. A reference type is at heart a pointer, and the pointer value follows the same rules for "allocation" as a value type, but once you store a value in it, ie. a reference to an object, that object is on the heap somewhere else.
In other words, the reference variable itself is "allocated" as a value type, but the object it refers to is on the heap.
When you construct an object from a class, space is allocated on the heap to fit all the fields of that class + some overhead in that space.
I seem to recall Jon Skeet having an article about the subject, I'm sure he'll jump in with an answer really soon so stay tuned.
It's more complicated than you might think. Even your claim that "value types are allocated on the stack" isn't correct. For example:
class Foo
{
int x;
}
int
is a value type, but the value for x will always be on the heap because it will be stored with the rest of the data for the instance of Foo which is a class.
Additionally, captured variables for anonymous functions and iterator blocks make life trickier.
I have an article about C# heap/stack memory you may find useful, but you might also want to read Eric Lippert's blog post on "The stack is an implementation detail". In particular, a future C# compiler could decide to store all of its local variables on the heap, using the stack just to hold a reference to an instance created at the start of the method... that wouldn't defy the C# spec at all.