When you print the memory map of a running process, which regions does it contain and what does each hold?

## A process is a set of mappings, not one pool When a program starts, the loader does not hand it a single undifferentiated block of memory. It builds a **memory map**: a list of address ranges, each backed by something and each carrying **permissions** - readable, writable, executable. Almost everything else in this subject follows from that map, because which range an address falls in decides how long its bytes live, who is allowed to change them, and what happens when the program tries. A conventional map for a running multi-threaded daemon holds these regions. - **Code** - the machine instructions of the program and of every library it loaded. Mapped readable and executable, not writable. One mapped copy serves every thread. - **Read-only constants** - literal text, jump tables, constant lookup tables: values fixed at build time that the program promises never to change. Mapped without write permission, which is why a store through a pointer into it traps. - **Initialized static data** - variables that live for the whole process and start at a non-zero value. Their starting bytes ship inside the program image. - **Zero-initialized static data** - the same process lifetime, but a starting value of zero. The image records only the size, and the loader supplies a zero-filled range. - **The heap** - one region per process. It grows on demand when the allocator asks the operating system for more address space, and blocks inside it are reclaimed explicitly or by a collector, depending on the ecosystem. - **Per-thread stacks** - one region per thread, each holding that thread's chain of active calls. Created with the thread, released when it exits. - **Thread-local storage** - a small block per thread holding variables declared as one-per-thread. It shares the thread's lifetime, but unlike the stack beside it, its contents outlive every individual call. ## The two questions that separate them | Region | How many | Program may write | Extent decided | Ends when | |---|---|---|---|---| | Code | one, shared | no | build time | process exits | | Read-only constants | one, shared | no | build time | process exits | | Initialized static data | one, shared | yes | build time | process exits | | Zero-filled static data | one, shared | yes | build time (size only) | process exits | | Heap | one, shared | yes | run time, grows | block released | | Stack | one per thread | yes | thread creation | frame returns, thread exits | | Thread-local storage | one per thread | yes | build and run time | thread exits | Read that table column by column and the whole subject is in it: **how many copies exist** and **may the program write** are the two axes that actually distinguish these regions from one another. ## Why the split exists 1. **Protection.** Marking instructions and constants non-writable turns a whole class of bugs - a stray pointer walking past the end of a buffer into code - into an immediate, localised fault instead of silent corruption discovered hours later. 2. **Sharing.** Because code and constants are never written, many processes running the same program can be given the same underlying copy. A region that is written cannot be shared that way. 3. **Cost.** Reserving a range is cheap; shipping bytes is not. A region whose contents are known to be all zeros needs only a size recorded, which is why a large zeroed static array costs nothing in the program file. ## What this buys you in an interview The next question is almost always *which region does this value land in, and why*, and the map is what you answer it with: - A value whose lifetime is the whole process and whose name is fixed at build time goes to static data. - A value that belongs to one call, in one thread, goes to that thread's stack. - A value whose size or lifetime is not settled until run time goes to the heap, which is why it costs a pointer hop and a reclamation obligation. - A value that must be one-per-thread rather than one-per-process goes to thread-local storage - a distinct region, not a flavour of either of the others. Notice how much the map explains with no further machinery: why running 800 threads instead of 8 multiplies part of the footprint and leaves the rest untouched (only the per-thread regions are duplicated); why two identical literals can legitimately share one address (a region nobody writes can be de-duplicated safely); why you cannot hand a value to another thread by leaving it on your own stack (that range belongs to your call chain). ## Where this stops The map is a list of address ranges, not a statement about physical memory. How those ranges are backed by hardware - page tables, what is resident, what has been paged out - is a separate operating-system subject, and so is any one platform's naming for its own runtime areas. Learn the regions and their rules first; the backing story sits underneath them and answers a different question.