Memory bigger than what's real
We said many processes run at once (lesson 2). Each of those programs needs memory, a place to remember. But real memory (RAM) comes in a fixed, limited amount. If they all grab real spots directly, it runs out and they collide. So the OS gives each one a 'pretend, larger memory'.
Everyone wants memory
Programs running at once each need a place to remember.
But real memory is a limited, small space.
If they all try to hold real spots directly,
spots run short fast and their areas collide.
It becomes a fight over memory.
Add more programs. The real memory bar fills and overflows fast.
Real memory alone can't handle them all.
But we can't tell a program 'give up your memory'.
Each needs to use plenty.
Here the OS pulls a clever trick.
Give each its own large memory
The OS gives each program one pretend memory.
Wide, starting cleanly from slot 0, looking like it's used alone.
A's 'slot 0' and B's 'slot 0' are actually different places.
Each sees only its own memory, and can't even see the others'.
This private pretend memory is called virtual memory.
Switch between programs A and B. Each has its own 'my memory' from slot 0.
Both use it cleanly from slot 0, which is handy.
But pretend addresses aren't real spots, right?
When a program says 'my slot 3',
who turns that into a real spot, and how?
Translate pretend addresses to real spots
Every time a program uses 'my slot 3',
the OS and hardware secretly turn it into a real spot.
A small map connects 'my 3 -> real 27', and so on.
A's 'my 0' is real 5; B's 'my 0' is real 40.
Same pretend number, different real spot, so they never collide.
Tap a pretend address. It routes through the map to a real spot. A and B reach different places from the same number.
The map turns pretend into real, so each lives safely apart.
But add up everyone's pretend memory
and it can be far bigger than real memory.
How do you fit all that into the small real memory?
Bigger than real: unused parts to disk
Here's the OS's secret.
Parts not used right now are pushed out to the slow disk for a while.
And the part needed now goes into that freed spot.
Later, if the pushed-out part is needed again, it's brought back.
So you can use a memory larger than the real one.
Bring in a new part. When real memory is full, an unused part goes to disk and the needed one comes in.
Pushing out and pulling back makes a bigger-than-real memory possible.
But disk is much slower than real memory, right?
Going all the way to disk every time would be sluggish.
The OS takes care of one more thing.
Keep the frequently-used close
The OS keeps the frequently-used parts in the nearby real memory.
Only the rarely-used ones go to the far, slow disk.
It's the very same idea as the cache we met in structure: 'keep the frequent close'.
So most of the time it finishes right in fast real memory,
and trips to disk are only occasional, so you barely feel the slowness.
Fetch many times. Frequent parts stay in real memory (close); rare ones on disk (far).
In short, virtual memory is the craft of mapping pretend addresses to real spots,
sending the unused to disk, and keeping the frequent close.
Thanks to it, each process feels like it uses a bigger-than-real memory alone.
But the fact that each sees only 'its own spots' and not others'
actually becomes the wall that separates and protects yours from mine. That's the next story.