# How is heap memory allocated to a process?

I want to better understand how OS provides heap memory to a process. Here by heap memory I mean the memory allocated dynamically, say by call to malloc.

1. When a process is newly created, does OS reserve some heap memory for it?
2. If a process calls malloc, does OS associate a "Page" (from paging concept) with process and then return some portion from that page? And so do later calls to malloc try to provide memory from this page, and if not possible OS associates another page from RAM(or virtual memory)?

Heap allocators typically call a system call to reserve a region of pages and then dole out chunks of that to new, malloc, and other higher-level calls. The system call on Unix used to be brk and sbrk, but implementations sometimes use mmap as well. I think windows uses VirtualAlloc, but it's not totally clear to me. A good resource for this is Wikipedia's page on C dynamic memory allocation.

• VirtualAlloc is the usual way to do this in Windows, yes. It does pretty much what mmap() does when you give it a file descriptor of -1. Incidentally, Mach (and hence OS X) has vm_allocate() which again does the same thing. Oct 28 '15 at 5:27

Short answer, summarizing the other answers: It is done by the operating system. Simple (early) operating systems assigned fixed size areas for code, data, stack + heap (with the idea that the stack and heap grew towards each other). Early Unix systems had a space for the stack and an area for data, used also by the heap (which could be extended with the specialized brk(2) and sbrk(2) system calls). More modern systems use virtual memory, and aren't bound by limited, contiguous address spaces anymore. So the program can ask for extra addresses (usually via mmap(2) or similar) and the library handling the heap doles out parts of that as asked.

How exactly this all works depends on the programming language (different languages pose different requirements) and the facilities the underlying kernel offers.

To answer your question 1, the short answer is yes. The long answer is when an executable is linked, there are also fields in the executable header (For Unix and Unix-Like operating systems, it's ELF. Windows uses PE32/64 for 32-bit and 64-bit.) that determine the initial size of the static data area, the stack, and the heap.

For your question 2, the short answer is "it depends." Since most modern operating systems today use virtual memory, it is common to use Virtual Memory Addressing where each program is given its own separate memory space. The size of this memory space is either 2^32 on 32-bit systems or 2^64 on 64-bit systems. A good discussion on the layout of a running program on Linux can be found here. A request to the operating system will map in more pages to extend the range of valid addresses for the program to use. These new ranges are backed by physical RAM until they are swapped out to disk.

With that being said, there are program types that are fixed in size. For example, from the old MS-DOS era, there is something known as a .COM (COre iMage) file which is an executable, but it is allocated a fixed 64k-bytes. Although, with the nature of the machines back in the day, a COM file could access the entire memory map of the machine without consequence. Other machine types have different versions of this. Current Unix implementations however, supports the ELF executable type, and possibly others such as a.out. Executable script files which are equivalent to .BAT and .CMD files on Windows, use an interpreter which is an ELF binary.

• “Unix however, only supports the ELF executable type” — that's not true. Different variants of Unix support different types of executables. ELF is the most common but not the only one. Dec 26 '15 at 17:02