The stack is the memory set aside as scratch space for a thread of execution.

• When a function is called, a block is reserved on the top of the stack for local variables and some bookkeeping data.
• When that function returns, the block becomes unused and can be used the next time when a function is called.
• The stack is always reserved in a LIFO (last in first out) order;
• the most recently reserved block is always the next block to be freed.
• This makes it really simple to keep track of the stack; freeing a block from the stack is nothing more than adjusting one pointer.

The heap is memory set aside for dynamic allocation.

• Unlike the stack, there’s no enforced pattern to the allocation and deallocation of blocks from the heap;
• therefore, you can allocate a block at any time and free it at any time.
• This makes it much more complex to keep stack of which parts of the heap are allocated or free at any given time;
• There are many custom heap allocators available to tune heap performance for different usage patterns.

Each thread gets a stack, while there’s typically only one heap for the application (although it isn’t uncommon to have multiple heaps for different types of allocation).

What is their scope?

• The stack is attached to a thread, so when the thread exits the stack is reclaimed.
• The heap is typically allocated at application startup by the runtime, and is reclaimed when the application (technically process) exits.

What determines the size of each of them?

• The size of the stack is set when a thread is created.
• The size of the heap is set on application startup, but can grow as space is needed (the allocator requests more memory from the operating system).

What makes one faster?

• The stack is faster because the access pattern makes it trivial to allocate and deallocate memory from it (a pointer/integer is simply incremented or decremented), while the heap has much more complex bookkeeping involved in an allocation or deallocation.
• Also, each byte in the stack tends to be reused very frequently which means it tends to be mapped to the processor’s cache, making it very fast.
• Another performance hit for the heap is that the heap, being mostly a global resource, typically has to be multi-threading safe, i.e. each allocation and deallocation needs to be - typically - synchronized with “all” other heap accesses in the program.

• Stored in computer RAM just like the heap, which is in different location, called “Automatic memory”.
• Variables created on the stack will go out of scope and are automatically deallocated.
• Much faster to allocate in comparison to variables on the heap.
• Implemented with an actual stack data structure.
• Stores local data, return addresses, used for parameter passing.
• Cause a stack overflow when too much of the stack is used (mostly from infinite or too deep recursion, very large allocations).
• Data created on the stack can be used without pointers.
• You would use the stack if you know exactly how much data you need to allocate before compile time and it is not too big.
• stack’s maximum size has been already determined when your program starts.

• Stored in computer RAM just like the stack, which is in “Dynamic memory”.
• In C/C++, variables on the heap must be destroyed manually and never fall out of scope. The data is freed with delete by delete[], or free by *free().
• Slower to allocate in comparison to variables on the stack.
• Used on demand to allocate a block of data for use by the program.
• Can have fragmentation when there are a lot of allocations and deallocations.
• In C/C++, data created on the heap will be pointed to by pointers and allocated with new or malloc respectively.
• Can have allocation failures if too big of a buffer is requested to be allocated.
• You would use the heap if you don’t know exactly how much data you will need at run time or if you need to allocate a lot of data.
• Responsible for memory leaks.

• Continuity in Logical Address let us find continuously the address by pointer.
• Discontinuity in Physical Address is caused by no more large enough space to store this variable.
• More details can be found in csdn