Relocation

What relocation does in memory loading

Relocation is the loader’s adjustment step for code and data that were built assuming one address but are being placed at another. It is part of how position-independent code and address randomization can coexist without breaking references.

The key idea is that relocation is not a logical program feature, it is a load-time transformation. The loader rewrites address-sensitive values so the program can still find functions, globals, and jump targets after the process image lands in a different part of memory.

Why relocation creates dirty pages

Relocation matters because the write it performs changes memory state before execution even begins. A page that started as read-only constant data in the executable can become dirty once the loader patches it, which affects how the operating system tracks sharing and memory use.

This is why relocation has operational consequences beyond correctness. Even when the underlying bytes are only being adjusted for address fixups, the act of writing can reduce page sharing across processes and increase memory pressure compared with truly untouched read-only pages.

How relocation supports position-independent code

Position-independent code is designed to run correctly regardless of where it is mapped, but it still may need relocation entries for values that cannot be fully encoded as relative references. Those entries tell the loader which words need fixup and how to compute the final value.

In practice, relocation is one of the mechanisms that lets modern address randomization work without requiring every instruction or data reference to be absolute. The program image can stay flexible, while the loader resolves the small set of address-dependent locations at startup.

What relocation means for performance and sharing

Relocation can be cheap in small amounts and expensive at scale. More relocation work means more loader activity, more memory writes during startup, and potentially less opportunity for the operating system to keep identical pages shared across processes.

That trade-off is why relocation is often discussed alongside binary layout, loader behavior, and memory efficiency. A binary that minimizes unnecessary address fixups is generally easier for the operating system to load efficiently and to share among multiple running instances.

Risk and Threat Considerations

Relocation is usually a normal part of executable loading, but it creates a narrow window where memory pages are modified before the program reaches steady state. That matters because load-time writes can affect page sharing, increase memory churn, and expose weaknesses in assumptions about pages remaining constant.

Failure mechanism: If a binary depends on too many address-sensitive writes, the loader must dirty more pages, which can increase memory footprint and reduce the efficiency benefits normally expected from shared executable pages.

Impact: The result is usually operational, not catastrophic, but at scale it can raise startup cost, reduce hosting density, and make memory behavior less predictable for systems that load many instances of the same program.