Segmentation

Segmentation

A program consists of logical segments such as code, data, stack, and heap. Segmentation supports this user view: modular development divides a process into differently sized segments, and physical memory into differently sized partitions. Each loaded segment occupies a separate contiguous partition; the segments of one process need not occupy adjacent partitions.

A segment table records mappings from a process's segments to physical partitions. Its basic fields are segment number, physical starting address, and segment length.

In systems using this segmentation model, the compiler, linker, and loader can organize code, global variables, heap, thread stacks, and library functions into segments. The loader loads and numbers these segments.

Segmentation lets programs avoid managing concrete physical addresses, but has drawbacks such as fragmentation and inefficient swapping.

There are two memory-utilization issues here:

1. External fragmentation: free physical memory is noncontiguous and lacks a large enough contiguous partition for a new process.
2. Infrequently used data remains resident: this reduces utilization but is not the unused allocation space called internal fragmentation.

Swapping and relocation can reorganize external fragmentation. For example, write a music process's 256MB to disk and reload it immediately after an occupied 512MB region. If this leaves 256MB contiguous free space, a new 200MB process can be loaded.

In a multiprocess system, segmentation readily produces fragmentation, and swapping can become a bottleneck. Disks are far slower than memory, and each swap transfers a large contiguous block to disk.