12

I want to know about runtime memory allocation on stack area and how its different from runtime memory allocation on Heap area.

I know how memory get allocated by using library function.

#include<alloca.h> void *alloca(size_t size); //(for runtime memory on stack)

#include<stdlib.h> void *malloc(size_t size); //(for run time memory on heap)

I also know that if we are using alloca function we don't need to free that memory explicitly because it is associated with stack, its get freed automatically.

I want to know which system calls are associated with alloc and malloc and how they works in both.

bash.d
  • 13,029
  • 3
  • 29
  • 42
Tiwari
  • 123
  • 1
  • 1
  • 6
  • What do you mean by `which system calls are associated with alloc and malloc`? Are you asking how the internals of `alloc()` and `malloc()` work? – Mike Mar 26 '13 at 14:48
  • `alloca` is nonstandard and the implementation of `malloc` is going to be very machine and compiler dependent. Can you provide some more specifics about what you want to know? – Carl Norum Mar 26 '13 at 14:48
  • Why it's important for you to know which system-call use `alloca`? AFAIK, `alloca` is deprecated and it's recommended to avoid using it. [_Why is alloca not considered good practice?_](http://http://stackoverflow.com/questions/1018853/) – masoud Mar 26 '13 at 14:48
  • What system calls? `brk()` and `sbrk()`? – Axel Mar 26 '13 at 14:52
  • 1
    `alloca` isn't deprecated, as it's never been part of a standard. It's very well supported (and heavily used) in GNU software -- they recommend its use. It's dependent on the implementation though, on other platforms it may be buggy or not even present. – teppic Mar 26 '13 at 14:56

3 Answers3

13

In short they usually don't use system calls, unless running out of available memory.

The bahavior is different for either, so I explain differently.

malloc

Let's say initially your program has 1MB (for example) available memory for allocation. malloc is a (standard) library function that takes this 1MB, looks at the memory you want to allocate, cut a part of the 1MB out and give it to you. For book-keeping, it keeps a linked-list of unallocated memories. The free function then adds the block being freed back to the free list, effectively freeing the memory (even though the OS still doesn't get any of it back, unless free decides that you have way too much memory and actually give it back to the OS).

Only when you run out of your 1MB does malloc actually ask the operating system for more memory. The system call itself is platform dependent. You can take a look at this answer for example.

alloca

This is not a standard function, and it could be implemented in various ways, none of which probably ever call any system functions (unless they are nice enough to increase your stack size, but you never know).

What alloca does (or equivalently the (C99) standard variable length arrays (VLA) do) is to increase the stack frame of the current function by adjusting proper registers (for example esp in x86). Any variable that happens to be on the same stack frame but located after the variable length array (or allocaed memory) would then be addressed by ebp + size_of_vla + constant instead of the good old simple ebp + constant.

Since the stack pointer is recovered to the frame of the previous function upon function return (or generally on exit of any {} block), any stack memory allocated would be automatically released.

Community
  • 1
  • 1
Shahbaz
  • 46,337
  • 19
  • 116
  • 182
3

The alloca() function is typically implemented by the compiler vendor, and doesn't have to be a "system call" at all.

Since all it needs to do is allocate space on the local stack frame, it can be implemented very simply and thus be incredibly fast when compared to malloc().

The Linux manual page for it says:

The inlined code often consists of a single instruction adjusting the stack pointer, and does not check for stack overflow.

Also, I'm not sure you realize that the memory gets deallocated "automatically" when the function that called alloca() exits. This is very important, you can't use alloca() to do long-lived allocations.

unwind
  • 391,730
  • 64
  • 469
  • 606
0

The alloca function is, according to its manpage a function that is inlined and will be specially treated by the compiler and expanded (at least for gcc).
The behavior is implementation-defined and as such, should not be used, for you cannot gurantee it to work the same way always.

bash.d
  • 13,029
  • 3
  • 29
  • 42
  • I think it's a bit harsh to say implementation extensions shouldn't be used -- it's fine as long as you're aware of how it might limit portability. – teppic Mar 26 '13 at 15:02
  • @teppic agreed, but as far as I know it should be avoided – bash.d Mar 26 '13 at 15:07