memory allocation in Stack and Heap

This may seem like a very basic question, but its been in my head so:

When we allocate a local variable, it goes into stack. Similarly dynamic allocation cause the variable to go on heap. Now, my question is, is this variable actually lie on stack or heap or we will just a reference in the stack and Heap.

For example,

Suppose I declare a variable int i. Now this i is allocated on the stack. So, when I print the a开发者_StackOverflowddress of i, this will be one of the location on stack? Same question for heap as well.

---

I'm not entirely sure what you're asking, but I'll try my best to answer.

The following declares a variable i on the stack:

int i;

When I ask for an address using &i I get the actual location on the stack.

When I allocate something dynamically using malloc, there are actually TWO pieces of data being stored. The dynamic memory is allocated on the heap, and the pointer itself is allocated on the stack. So in this code:

int* j = malloc(sizeof(int));

This is allocating space on the heap for an integer. It's also allocating space on the stack for a pointer (j). The variable j's value is set to the address returned by malloc.

---

Hopefully the following is helpful:

void foo()
{
    // an integer stored on the stack
    int a_stack_integer; 

    // a pointer to integer data, the pointer itself is stored on the stack
    int *a_stack_pointer; 

    // make a_stack_pointer "point" to integer data that's allocated on the heap
    a_stack_pointer = (int*)malloc(10 * sizeof(int));
}

In the case of stack variables, the variable itself (the actual data) is stored on the stack.

In the case of heap allocated memory, the underlying data is always stored on the heap. A pointer to this memory/data may be stored locally on the stack.

Hope this helps.

---

The pointer variable itself would reside on the stack. The memory that the pointer points to would reside on the heap.

int *i = malloc(sizeof(int));

i would reside on the stack, the actual memory that i points to *i would be on the heap.

---

I agree with Chris. Just another way to explain that. Consider the following code:

int* j = malloc(sizeof(int));
free(j);

Even after using free(j) which should deallocate the memory from the heap, the pointer still exists and we need to explicitly make it NULL. This definitely suggests that there is also a stack counterpart of the pointer otherwise it should have been inexistent after the free command. This stack variable is the one pointing to the address on the heap where the memory was dynamically allocated using malloc.

---

Mr. Eberle's answer is 100% correct, but since Google shows this as the first answer when searching for malloc heap or stack, I have to add that malloc() allocates data on the heap 'most' of the time. If the allocated data was larger than MMAP_THRESHOLD which is usually 128kb on 32-bit systems, malloc() will not use the heap and instead allocates the data in an Anonymous Memory Segment located usually below the stack, growing in the direction of low memory.

This is the same region that dynamically loaded libraries are located (libc.so, etc.). Here's the relevant passage from man malloc:

Normally, malloc() allocates memory from the heap, and adjusts the size of the heap as required, using sbrk(2). When allocating blocks of memory larger than MMAP_THRESHOLD bytes, the glibc malloc() implementation allocates the memory as a private anonymous mapping using mmap(2). MMAP_THRESHOLD is 128 kB by default, but is adjustable using mallopt(3). Prior to Linux 4.7 allocations performed using mmap(2) were unaffected by the RLIMIT_DATA resource limit; since Linux 4.7, this limit is also enforced for allocations performed using mmap(2).

As a practical example, feel free to check the following post. It basically allocates 300kb with malloc() and then runs pmap <PID> to show the relevant memory segment.

---

stack or heap are not separate memory, they are memory segments that a running program is allocated by the system, just different ways of organizing data in memory.

So when you get &i, it is a memory address, simple as that.