47

Possible Duplicate:
What and where are the stack and heap

I have a couple of questions on stack versus heap.

The basic thing to know is that stack is faster than the heap, but is limited. (correct me if I'm wrong).

However, I always wondered how stack and heap work exactly. RAM is just one chunk of memory, it isn't divided into 'stack' and 'heap' (or is it?). If so, why do we split up the memory in stack and heap in the first place?

OS's could just allow us to be able to allocate everything on the stack -> everything goes faster -> happy world?

I'm pretty sure that's not the case. But Why!? Can anyone give me an in-depth answer?

Sorry if this post is a duplicate of some post ever made by some person, there's so many related to stack and heap, I couldn't find the exact question I had. If you happen to know one, go ahead and link it.

trincot
  • 317,000
  • 35
  • 244
  • 286
xcrypt
  • 3,276
  • 5
  • 39
  • 63

3 Answers3

51

Stack: The stack is used as a sort of temporary scratch pad for use by the block of code that's currently executing, and whatever block called the current one, and whatever block called that one, and so on. When the current block exits, the local variables it was using are forgotten. As the name indicates, the stack is used in a last-in, first-out manner.

One of the most important uses of the stack is to keep track of the current call chain. When one function calls another, the caller pushes the address of the next instruction (the return address) onto the stack. As each function exits, it pops its caller's return address off the stack and continues executing code starting at that address. It's also used for communicating function parameters and return values between caller and callee.

Heap: The heap is different -- there's no particular order to it. If you want to allocate memory in a block of code and have that memory stick around beyond the end of the block, you allocate it on the heap. Of course, you'll also need to store a pointer/reference to it somewhere so that other code can find that memory; most languages provide accommodation for that.

Speed: Differences in speed aren't due to any property of the memory itself -- as you say in your question, both stack and heap typically inhabit the same physical memory. Allocating space on the stack is quick due to the stacks LIFO nature: if you push something onto the stack, there's only one place it can end up. By contrast, allocating a block on the heap requires finding a large enough contiguous free region in memory. A stack allocation can be as quick as a single instruction; a heap allocation requires a call to a memory allocation function like malloc().

Static v. dynamic: Allocating memory on the heap is dynamic -- whether to allocate a block, and the size of the block, can be determined according to input the program receives while it's running. Regions of memory allocated on the heap can even be resized if necessary. It's possible to dynamically allocate memory on the stack, too (see the C standard library function alloca()), but that memory will be lost as soon as the current function exits. Stack allocations are usually static -- the compiler determines how much space is needed for the (non-register) parameters, return data, and local variables, and it generates code to reserve the necessary space on the stack when the function is called.

Example: Imagine that you're creating a word processor. You can't know ahead of time how large the document will be, or even how many documents will be in use at the same time. At the same time, you want the user's documents to remain in memory as long as the user wants to keep them open. If you try to allocate memory for the documents on the stack you'll find it difficult to have more than one open at once, and you'll need to create a single function that creates, edits, saves, and closes the document. Allocating the space on the heap allows you to create as many documents as you like, each sized appropriately for the data it contains, and to avoid tying the lifetime of the documents to the lifetime of any particular function.

Summary: In a nutshell, the stack holds the values of variables (sometimes registers are used instead), while the heap is used for allocating memory that will be used beyond the lifetime of the current block.

Caleb
  • 124,013
  • 19
  • 183
  • 272
  • 1
    Could you give me an example of some point where I am forced to use the heap? For example, I could just allocate everything on the stack I need for the entire program in the parent function, and pass everything by address to the child functions. EDIT: let's ignore that the stack is limited by anything else than the RAM memory being full, for the sake of the question. – xcrypt Nov 17 '11 at 20:38
  • 1
    @xcrypt That would require that you know in advance about every memory allocation that your program might perform. Alternately, you could allocate a giant block on your stack from which you could later dynamically allocate memory. That block would be the functional equivalent of a heap. I'll add an example above. – Caleb Nov 17 '11 at 20:46
  • You mentioned that the compiler figures out the amount of stack space it needs before runtime, right? Is that true for the case of recursion too? Because if that's right then shouldn't the compiler be able to prompt an infinite recursion right after compiling the code? – Dubby Jul 18 '14 at 22:45
  • @Dubby Answering your question 3 years later... a compiler can look at a function and figure out how much local storage it needs, but in general it can't know how much storage will be needed by other functions that the function calls, including recursive calls. Decisions about which functions to call and when happen at run time in response to data that the compiler can't know, so it can't know how much total stack space will be used, how long a recursive process will go on, etc. – Caleb Sep 08 '17 at 13:22
  • 1
    The best answer on stack vs heap. Thanks, my man! – Yusufbek Jul 11 '22 at 14:31
14

You cannot only use a stack, because a stack requires a last-in first-out allocation & deallocation order (i.e. you can only deallocate the newest allocated data; in a stack you cannot deallocate some old data and keep some newer one).

Actually, you can get rid of the stack (only keeping the heap). See Appel's paper Garbage Collection Can Be Faster Than Stack Allocation and his Compiling with Continuation book.

And heap does not have a well defined meaning (other than "dynamically allocated memory which is not on the stack"). Actually, on Linux systems, allocating a big chunk of memory using the mmap system call is fairly quick (but malloc implementations try to avoid mmap and prefer reusing free-d memory). The issue is allocation of small memory zones.

And read more about garbage collection techniques. In C or C++ you might use Boehm's GC

A stack is often useful, notably for recursive function calls. It is so useful (e.g. in C) that today's processors usually have a dedicated stack pointer register (used by CALL & RET machine instructions for calling & returning). But this was not always the case; on some processors (eg IBM360), the stack pointer is a conventional register, not a hardcoded one.

See also this & that answers (and other ones) about virtual address space.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • very helpful information, thanks :) – xcrypt Nov 17 '11 at 20:21
  • Would you mind elaborating on why stack only is not feasible? Intuitively this is true because with only one stack we got the pushdown automata, which is not equivalent to Turing Machine. But what if a language supports only pure functionss (like Haskell) and use not references (i.e. all value types)? Everything is either passed in as arguments or returned as results. Is it possible to implement this language with only a stack? Could this language be Turing-complete? – wlnirvana Dec 10 '19 at 09:40
1

The memory is just the same for both of them, but the stack and the heap are 2 different data structures that are useful for different purposes.

Stack is a very primitive abstraction that is needed by any micro processor in order to execute instructions on a couple of operands (usually processor registers or memory addresses).

The heap is a general allocation memory area where usually you want to store data that is not bound to the stack, that is their lifetime is longer that if stored in the stack, or said another way, the data is going to be accesses by different portions of code.

Gabriel Belingueres
  • 2,945
  • 1
  • 24
  • 32
  • Well, I could just allocate some object on the stack in the main function, and use it throughout the entire program, I don't need heap for that. Your argument could be that the stack is limited, but one of things I intended to ask with my questions was: Why is the stack limited? (for reasons mentioned above) – xcrypt Nov 17 '11 at 20:16
  • The stack is limited because it grows from one extreme of the memory space address to the other extreme. If it were unlimited, then you may corrupt date stored in the heap when an interruption is attended (because the interruption saves the CPU state in the stack), so an artificial limit must be put in place somewhere to avoid this (and that's because exist the famous 'stack overflow' message when you reach that limit). – Gabriel Belingueres Nov 19 '11 at 14:01