Skip to main content

Aside Every Address You See Is Virtual

This page is a generated reference surface for selective reading. It exists to keep the learner apps guide-first while still preserving source access.

Learning objectives​

  • Explain the main ideas and vocabulary in Aside Every Address You See Is Virtual.
  • Work through the source examples for Aside Every Address You See Is Virtual without depending on raw chunk order.
  • Use Aside Every Address You See Is Virtual as selective reference when learner modules point back to Ostep.

Prerequisites​

  • None curated yet.

Module targets​

  • module-02-memory-management-virtual-memory

AI companion modes​

  • Explain simply
  • Socratic tutor
  • Quiz me
  • Challenge my understanding
  • Diagnose my confusion
  • Generate extra practice
  • Revision mode
  • Connect forward / backward

Source-of-truth note​

This unit is anchored to Ostep and the source chapter "Aside Every Address You See Is Virtual". Use external resources only to clarify, extend, or modernize details without replacing the chapter's conceptual spine.

External enrichment​

No chapter-specific enrichment resources are curated yet. Add them in the unit manifest when a source clearly improves learning.

Source provenance​

  • Primary source: Ostep
  • Source chapter: Aside Every Address You See Is Virtual
  • Raw source file: 057-aside-everyaddressyouseeisvirtual.md

Merged source​

Aside Every Address You See Is Virtual​

ASIDE: EVERYADDRESSYOUSEEISVIRTUAL

Ever write a C program that prints out a pointer? The value you see (some large number, often printed in hexadecimal), is avirtual address.

Ever wonder where the code of your program is found? You can print that out too, and yes, if you can print it, it also is a virtual address. In fact, any address you can see as a programmer of a user-level program is a virtual address. It's only the OS, through its tricky techniques of virtualizing memory, that knows where in the physical memory of the machine these instructions and data values lie. So never forget: if you print out an address in a program, it's a virtual one, an illusion of how things are laid out in memory; only the OS (and the hardware) knows the real truth.

Here's a little program that prints out the locations of themain()routine (where code lives), the value of a heap-allocated value returned from

malloc(), and the location of an integer on the stack:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[]) {
printf("location of code : %p\n", (void *) main);
printf("location of heap : %p\n", (void *) malloc(1));
int x = 3;
printf("location of stack : %p\n", (void *) &x);
return x;
}

When run on a 64-bit Mac OS X machine, we get the following output:

location of code : 0x1095afe50 location of heap : 0x1096008c0 location of stack : 0x7fff691aea64

From this, you can see that code comes first in the address space, then the heap, and the stack is all the way at the other end of this large virtual space. All of these addresses are virtual, and will be translated by the OS and hardware in order to fetch values from their true physical locations.

In the next chapters, we'll focus our exploration on the basicmechanismsneeded to virtualize memory, including hardware and operating systems support. We'll also investigate some of the more relevantpoliciesthat you'll encounter in operating systems, including how to manage free space and which pages to kick out of memory when you run low on space. In doing so, we'll build up your understanding of how a modern virtual memory system really works3.

3Or, we'll convince you to drop the course. But hold on; if you make it through VM, you'll likely make it all the way!

We have seen the introduction of a major OS subsystem: virtual memory. The VM system is responsible for providing the illusion of a large, sparse, private address space to programs, which hold all of their instructions and data therein. The OS, with some serious hardware help, will take each of these virtual memory references, and turn them into physical addresses, which can be presented to the physical memory in order to fetch the desired information. The OS will do this for many processes at once, making sure to protect programs from one another, as well as protect the OS. The entire approach requires a great deal of mechanism (lots of low-level machinery) as well as some critical policies to work; we'll start from the bottom up, describing the critical mechanisms first. And thus we proceed!