.Net Framework Clarification on Stacks and Heaps

I was reading through January issue of MSDN on the article "Identify And Prevent Memory Leaks In Managed Code", where (James Kovacs) started discussing stacks and heaps. I and a couple of other co-workers where wondering about more details on what they do and why they are needed.

Stacks: "The stack is where local variables, method parameters, return values, and other temporary values are stored during the execution of an application. A stack is allocated on a per-thread basis and serves as a scratch area for the thread to perform its work. The GC [Garbage Collector] is not responsible for cleaning up the stack because the space on the stack reserved for a method call is automatically cleaned up when a method returns. Note, however, that the GC is aware of references to objects stored on the stack. When an object is instantiated in a method, its reference (a 32-bit or 64-bit integer depending on the platform) is kept on the stack, but the object it-self is stored on the managed heap and is collected by the garbage collector once the variable has gone out of scope."

Unmanaged Heap: "The unmanaged heap is used for runtime data structures, method tables, Microsoft intermediate language (MSIL), JITed code and so forth. Unmanaged code will allocate objects on the unmanaged heap or stack depending on how the object is instantiated. Managed code can allocate unmanaged heap memory directly by calling into unmanaged Win32 APIs or by instantiating COM objects. The CLR itself uses the unmanaged heap extensively for its data structures and code."

Managed Heap: "The managed heap is where managed objects are allocated and it is the domain of the garbage collector. The CLR uses a generational, compacting GC. The GC is generational in that it ages objects as they survive garbage collections; this is a performance enhancement. All versions of the .NET Framework have used three generations, Gen0, Gen1, and Gen2 (from youngest to oldest). The GC is compacting in that it relocates objects on the managed heap to eliminate holes and keep free ememory contiguous. Moving large objects is expensive and therefore the GC allocates them on a separate Large Object Heap, which does not compact."