Possible Duplicate:
What and where are the stack and heap?
With regard to the basic concepts of memory layout in a c program, I understand the that:
Stack is accessed through a last-in, first-out (LIFO) memory allocation system. Heap Space exists as long as the application runs and is larger than Stack, which is temporary, but faster.
Initial heap size is 1/64th of the computer's physical memory or reasonable minimum based on platform (whichever is larger) by default. The initial heap size can be overridden using -Xms. Maximum heap size is 1/4th of the computer's physical memory or 1 GB (whichever is smaller) by default.
Typically a fixed size of stack is allocated for every process by the OS which is platform-specific. There's no limit on heap size, program usually have all of the available virtual address space.
Whenever a method is invoked, a new block is created in the stack memory for the method to hold local primitive values and reference to other objects in the method. As soon as the method ends, the block becomes unused and becomes available for the next method. Stack memory size is very less compared to Heap memory.
As mentioned already, sizes are OS specific. For e.g. on windows using Visual Studio, default stack size is 1MB
msdn
On Linux the following command can show show your current one.
ulimit -s or -a
On my Linux mint 64 bit it shows 8192 KB.
Every program when loaded in memory has several segments. In assembly one can indicate each of those using .data, .code etc prefix (intelx86).
It is data segment which has several sub sections. Both stack and heap are part of it in addition to several others.
Stack can also grow implicitly i.e. when you make another function call, an activation record is pushed on to stack, they by utilizing more memory of stack. That is why infinite recursion results in crash when a program runs out of allocated stack.
When a function call returns, that activation record is popped and stack shrinks.
In contrast heap grows from the opposite direction and contains all dynamically allocated memory.
The reason these two segments grow in opposite direction is to maximize the utilization of their combined memory. Note that as mentioned in comments this is not a c standard, but most common OS's have this implemented.
------ stack starts ----------- stack grows downward
-------- Unless they cross each other a program is okay to run.
------- heap starts ------------heap grows upwards
If your program uses no heap, your stack can utilize maximum memory including that of heap too. If program makes few recursive calls and uses minimum local variables (i.e. uses less memory for stack), it can utilize heap to the most.
Other parts of data segment are BSS etc. which might contain fields such as uninitialized static variables
"Stack is created in the top-level-address and the heap at the low-level-address" Please elobarate this
This is a myth. It may have a basis in historical truth. It might sometimes resonate with things you see in real life. But it is not literally true.
It's easy enough to explore, though:
#include <stdlib.h> #include <stdio.h> void check(int depth) { char c; char *ptr = malloc(1); printf("stack at %p, heap at %p\n", &c, ptr); if (depth <= 0) return; check(depth-1); } int main() { check(10); return 0; }
On my machine I see:
stack at 0x22ac3b, heap at 0x20010240 stack at 0x22ac0b, heap at 0x200485b0 stack at 0x22abdb, heap at 0x200485c0 stack at 0x22abab, heap at 0x200485d0 stack at 0x22ab7b, heap at 0x200485e0 stack at 0x22ab4b, heap at 0x200485f0 stack at 0x22ab1b, heap at 0x20048600 stack at 0x22aaeb, heap at 0x20048610 stack at 0x22aabb, heap at 0x20048620 stack at 0x22aa8b, heap at 0x20048630 stack at 0x22aa5b, heap at 0x20048640
So, the stack is going downwards and the heap is going upwards (as you might expect based on the myth), but the stack has the smaller address, and they are not growing toward each other (myth busted).
Btw, my check
function is tail-recursive, and on some implementations with some compiler options you might see the stack not moving at all. Which tells you something about why the standard doesn't mandate how all this works -- if it did it might inadvertently forbid useful optimizations.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With