Thrashing
Virtual Memory promises that you have infinite RAM.
But this check is written against the Hard Disk (or SSD). And the Disk is the slowest bank in the universe.
The Cliff
As long as your program's "Working Set" (the pages it is currently touching) fits in Physical RAM, everything is fine.
But the moment you touch RAM_SIZE + 1 pages, you fall off a cliff.
To bring in the new page, the OS must Swap Out an old page to disk. To read a byte, you must wait milliseconds (millions of cycles).
1. Fill RAM: Click Page 1, 2, 3. Fast.
2. Overflow: Click Page 4. RAM is full. Watch the Disk LED. CPU halts.
3. Thrash: Now click Page 1 again. It was evicted! We have to swap it back in.
If you toggle between 4 pages in a 3-page RAM, your computer does 0 work. It only swaps.
Why SSD Doesn't Save You
Modern NVMe SSDs are fast. They can read in 100 microseconds.
But 100 microseconds is still 400,000 CPU Cycles.
Compared to RAM (100 cycles), it is still 4,000x slower. Swapping to an SSD is like walking to the moon instead of walking to Mars. You are still dead.
Why does my computer freeze when RAM is full?
Because the Window Manager, the Mouse Driver, and the Browser are all fighting for RAM. When the OS has to swap in the code just to move the mouse cursor, the UI freezes. This is Thrashing.
Part VII Conclusion.
We have seen Entropy. We have seen the OS slice time and fragment space.
We now know that "Performance" is a negotiation with a hostile environment.
But valid code eventually runs. Instructions eventually execute.
What happens inside the decoding chamber? What happens before the code even runs?
It is time to look at Execution Reality.