Processes
Process and Programs
A process is an instance of an executing program.
In contrast, a program is a file containing a range of information that describes how to construct a process at run time. This information includes the following:
Binary format identification: Each program file includes metainformation describing the format of the executable file. This enables the kernel to interpret the remaining information in the file. Historically, two widely used formats for UNIX executable files were the original a.out (“assembler output”) format and the later, more sophisticated COFF (Common Object File Format). Nowadays, most UNIX implementations (including Linux) employ the Executable and Linking Format (ELF), which provides a number of advantages over the older formats.
Machine-language instructions: These encode the algorithm of the program.
Program entry-point address: This identifies the location of the instruction at which execution of the program should commence.
Data: The program file contains values used to initialize variables and also literal constants used by the program (e.g., strings).
Symbol and relocation tables: These describe the locations and names of functions and variables within the program. These tables are used for a variety of purposes, including debugging and run-time symbol resolution (dynamic linking).
Shared-library and dynamic-linking information: The program file includes fields listing the shared libraries that the program needs to use at run time and the pathname of the dynamic linker that should be used to load these libraries.
Other information: The program file contains various other information that describes how to construct a process.
One program may be used to construct many processes, or, put conversely, many processes may be running the same program.
We can recast the definition of a process given at the start of this section as follows:
a process is an abstract entity, defined by the kernel, to which system resources are allocated in order to execute a program.
From the kernel's point of view, a process consists of user-space memory containing program code and variables used by that code, and a range of kernel data structures that maintain information about the state of the process. The information recorded in the kernel data structures includes various identifier numbers (IDs) associated with the process, virtual memory tables, the table of open file descriptors, information relating to signal delivery and handling, process resource usages and limits, the current working directory, and a host of other information.
Process ID and Parent Process ID
Each process has a process ID (PID), a positive integer that uniquely identifies the process on the system. Process IDs are used and returned by a variety of syscalls. For example, the kill() syscall allows the caller to send a signal to a process with a specific PID. The PID is also useful if we need to build an identifier that is unique to a process. A common example of this is the use of the PID as part of a process-unique filename. The getpid() syscall returns the PID of the calling process.
Each process has a parent—the process that created it. A process can find out the process ID of its parent using the getppid() syscall.
Memory Layout of a Process
The memory allocated to each process is composed of a number of parts, usually referred to as segments. These segments are as follows:
The text segment (.text) contains the machine-language instructions of the program run by the process. The text segment is made read-only so that a process doesn't accidentally modify its own instructions via a bad pointer value. Since many processes may be running the same program, the text segment is made sharable so that a single copy of the program code can be mapped into the virtual address space of all of the processes.
The initialized data segment (.data) contains global and static variables that are explicitly initialized. The values of these variables are read from the executable file when the program is loaded into memory.
The uninitialized data segment (.bss) contains global and static variables that are not explicitly initialized. Before starting the program, the system initializes all memory in this segment to 0. For historical reasons, this is often called the bss segment, a name derived from an old assembler mnemonic for "block started by symbol". The main reason for placing global and static variables that are initialized into a separate segment from those that are uninitialized is that, when a program is stored on disk, it is not necessary to allocate space for the uninitialized data. Instead, the executable merely needs to record the location and size required for the uninitialized data segment, and this space is allocated by the program loader at run time.
The stack is a dynamically growing and shrinking segment containing stack frames. One stack frame is allocated for each currently called function. A frame stores the function’s local variables (so-called automatic variables), arguments, and return value.
The heap is an area from which memory (for variables) can be dynamically allocated at run time. The top end of the heap is called the program break.
Pictorially:
Virtual Memory Management
Like most modern kernels, Linux employs a technique known as virtual memory management. The aim of this technique is to make efficient use of both the CPU and RAM (physical memory) by exploiting a property that is typical of most programs: locality of reference. Most programs demonstrate two kinds of locality:
Spatial locality is the tendency of a program to reference memory addresses that are near those that were recently accessed (because of sequential processing of instructions, and, sometimes, sequential processing of data structures).
Temporal locality is the tendency of a program to access the same memory addresses in the near future that it accessed in the recent past (because of loops).
The upshot of locality of reference is that it is possible to execute a program while maintaining only part of its address space in RAM.
A virtual memory scheme splits the memory used by each program into small, fixed-size units called pages. Correspondingly, RAM is divided into a series of page frames of the same size. At any one time, only some of the pages of a program need to be resident in physical memory page frames; these pages form the so-called resident set. Copies of the unused pages of a program are maintained in the swap area—a reserved area of disk space used to supplement the computer's RAM—and loaded into physical memory only as required. When a process references a page that is not currently resident in physical memory, a page fault occurs, at which point the kernel suspends execution of the process while the page is loaded from disk into memory.
In order to support this organization, the kernel maintains a page table for each process:
The page table describes the location of each page in the process's virtual address space (the set of all virtual memory pages available to the process). Each entry in the page table either indicates the location of a virtual page in RAM or indicates that it currently resides on disk.
The implementation of virtual memory requires hardware support in the form of a paged memory management unit (PMMU). The PMMU translates each virtual memory address reference into the corresponding physical memory address and advises the kernel of a page fault when a particular virtual memory address corresponds to a page that is not resident in RAM.
The Stack and Stack Frame
The stack grows and shrinks linearly as functions are called and return. For Linux on the x86-32 architecture (and on most other Linux and UNIX implementations), the stack resides at the high end of memory and grows downward (toward the heap). A special-purpose register, the stack pointer, tracks the current top of the stack. Each time a function is called, an additional frame is allocated on the stack, and this frame is removed when the function returns.
Sometimes, the term user stack is used to distinguish the stack we describe here from the kernel stack. The kernel stack is a per-process memory region maintained in kernel memory that is used as the stack for execution of the functions called internally during the execution of a syscall. (The kernel can’t employ the user stack for this purpose since it resides in unprotected user memory.)
Each (user) stack frame contains the following information:
Function arguments and local variables: In C these are referred to as automatic variables, since they are automatically created when a function is called. These variables also automatically disappear when the function returns (since the stack frame disappears), and this forms the primary semantic distinction between automatic and static (and global) variables: the latter have a permanent existence independent of the execution of functions.
Call linkage information: Each function uses certain CPU registers, such as the program counter, which points to the next machine-language instruction to be executed. Each time one function calls another, a copy of these registers is saved in the called function’s stack frame so that when the function returns, the appropriate register values can be restored for the calling function.
Since functions can call one another, there may be multiple frames on the stack. (If a function calls itself recursively, there will be multiple frames on the stack for that function.) For example, imagine a program with the calling chain main() => doCalc() => square(), the stack will contain frames as shown in the following diagram:
Reference
Last updated
