How do the stack, heap and frame conceptually map to c# constructs?

Answer 1

Are you talking about the data structure stack, are you talking about "stack" as in a stack machine or are you talking about "stack" as in a call stack? Are you talking about the data structure heap or are you talking about "heap" as in a free-store heap used for dynamic memory allocation? By "frame" I am presuming that you mean a certain part of the call stack (the stack frame) but since your question is otherwise quite vague, it would be helpful if you provided clarification on what you mean by that too.

If you mean the data structure concepts, then there is a Stack type in the System.Collections namespace as well as a generic version in the System.Collections.Generic namespace. There is, however, no heap provided in the .NET Framework. I do not know what you mean by "frame" in this case.

If you are talking about the machine concepts of stack and heap, then what you might be after is reading about the CLR. You can access StackTrace and StackFrame in the System.Diagnostics namespace to understand "stack" and "frame" in this context. You can read about the garbage collector to understand "heap" in this context.

Answer 2

I'm going to make some assumptions about your question:

the .NET call stack (and info for individual frames) are directly accessible via the StackFrame and StackTrace classes in System.Diagnostics.

in .NET, the garbage collector manages "heap" allocations. There are 3 generations of objects, the oldest living in generation 2 at the bottom of the heap. generation 0 is where new objects get allocated from. In addition, large objects are allocated in a separate section.

Answer 3

Here are my articles on this subject.

http://blogs.msdn.com/ericlippert/archive/2009/02/17/references-are-not-addresses.aspx

http://blogs.msdn.com/ericlippert/archive/2009/04/27/the-stack-is-an-implementation-detail.aspx

http://blogs.msdn.com/ericlippert/archive/2009/05/04/the-stack-is-an-implementation-detail-part-two.aspx

http://blogs.msdn.com/ericlippert/archive/2009/06/08/out-of-memory-does-not-refer-to-physical-memory.aspx

http://blogs.msdn.com/ericlippert/archive/2009/06/29/the-void-is-invariant.aspx

http://blogs.msdn.com/ericlippert/archive/2009/07/13/iterator-blocks-part-two-why-no-ref-or-out-parameters.aspx

http://blogs.msdn.com/ericlippert/archive/2009/07/27/iterator-blocks-part-six-why-no-unsafe-code.aspx