EXECUTING
NOTE:- For the best experience, this 3D simulation is highly visual. We recommend opening it on a desktop or laptop.
Choose which applications to include. Each one opens as a tab in Chrome on the 3D laptop and is modelled as one logical process. Clicking a tab triggers a simulated context switch.
Simplified model: real browsers spread a single tab across several processes and threads, and the OS switches contexts constantly on its own. See About for what this simulation does and does not claim.
Context switching is the process the CPU follows to change from one task (or process) to another. It is the process of saving and restoring the state (context) of a CPU so that multiple processes can share a single CPU efficiently. It's a fundamental feature of multitasking operating systems, allowing multiple processes to share a single CPU core, creating the illusion of simultaneous execution.
It occurs in multitasking operating systems when the CPU switches from executing one process to another.
Figure 1. Three tabs are modelled as three logical processes. There is one core, so only one runs at any instant. The other two sit in a ready queue waiting for a turn, and the context each one needs in order to resume is held in its control block. The block is where the state is kept — it is not the queue itself.
This is a conceptual visualisation of OS context switching, not a literal recording of your machine. Three simplifications are worth stating plainly:
Everything else — what a PCB contains, what gets saved and restored, why the program counter matters, why memory stays in RAM, and why the switch is pure overhead — follows standard operating-system theory.
Everything on screen maps onto one part of the real mechanism. Once you know the mapping, the animation reads as an operating system doing its job.
+ button spawns a new one and closing a tab with × terminates it and releases its block.Four kinds of object appear on the right of the screen, and it is worth naming them clearly:
PCB- plus the app name.Figure 2. Each process gets a slice, and between slices sits pure overhead. Shorter slices feel more responsive but waste a larger share of the processor. That trade-off is the whole design problem of a scheduler.
This is the distinction most descriptions of context switching gloss over, and getting it wrong makes the whole mechanism seem implausible. A process's memory — its code, its data, its decoded video frames — sits in RAM and does not move during a switch. The Process Control Block holds only the kernel's bookkeeping for that process: who it is, where it stopped, and how to find its memory.
Figure 6. The split that makes context switching cheap enough to happen thousands of times a second. If a switch had to move the left-hand box, multitasking would be impossible.
The page table is a useful example of the difference. On a switch the operating system does not copy the table; it hands the memory management unit a pointer to the incoming process's map. In the simulation you can see this as a single green packet travelling from the block to the small MMU chip on the processor package, distinct from the yellow register packets.
The memory in this scene is drawn as a SO-DIMM — a Small Outline Dual In-line Memory Module — because everything here belongs to a laptop. If you opened the machine on the left, this is the part you would find.
Figure 7. The simulation shows a SO-DIMM because the scene is a laptop. Nothing about context switching changes with the package — but it is the module you would actually find if you opened the machine on the left.
Press the RAM button in the top bar, or simply click the module in the scene, to fly the camera to it. The panel above it lists every process resident in memory with its colour and size, and highlights whichever one currently holds the processor.
Most explanations stop at "the registers are saved", which is hard to feel. In this simulation every tab also carries visible state, and it only moves forward while that tab owns the CPU:
That frozen-and-resumed behaviour is the context. If the OS failed to save it, the tab would restart from scratch every time you looked away.
Figure 3. Zoom into any green board in the simulation and you are looking at this, built as real chips. The Program Counter and the saved Registers are the two that matter most: one remembers where execution stopped, the other remembers what it was holding.
Zoom into any board and the name of every field appears beside its chip. In beginner mode you will find:
Switch to Advanced Mode before starting and the boards grow to include scheduling information, accounting data, the open file table, the IPC queue, memory limits and a running count of context switches.
The memory module sits at the top right of the scene, with a coloured band for every app open in the browser. It exists to correct a common misunderstanding: a process that is not running has not been unloaded — it still occupies memory while it waits its turn.
How this model simplifies memory. Each process here is shown as fully resident in RAM, and switching never changes an allocation; closing a process releases its simulated allocation. A real operating system is far more dynamic — virtual memory, demand paging, shared and file-backed pages, memory compression, swapping and reclamation all mean a process can exist without every page of its address space sitting in physical RAM, and memory can be reclaimed while the process is still alive. The fixed bands here exist to make one distinction visible: memory residency is not the same as CPU execution.
The megabyte figures on the module are illustrative values chosen to be readable, not measurements of real applications.
Figure 4. The memory module in the scene answers a question most people have: if the other apps are not running, where are they? They are right here, loaded and waiting, holding their place.
CPU registers are small, extremely fast storage locations within the CPU itself. They are crucial for any computation. The values in these registers change constantly as a program executes its instructions.
Because each process has its own unique set of register values at any given moment, these values are the most critical part of the "context" that must be saved and restored during a switch.
Suppose the video player needs to advance its frame counter by one. In machine terms that is roughly three instructions:
LOAD R1, frameCount
ADD R1, 1
STORE frameCount, R1
PC holds the address of LOAD — say 0x7024. After it runs, PC becomes 0x7026, then 0x7028. The Program Counter is simply a bookmark that walks forward.R1 now physically holds the frame number. It is not in memory; it is inside the processor.ADD and STORE. R1 holds a number that exists nowhere else in the entire computer, and PC is the only record of how far through the sequence we got.Lose either one and the process is corrupted: it would resume at the wrong instruction, or add one to a number it no longer has. That is why the register file, small as it is, is the heart of what gets saved.
Figure 5. The same four registers, before and after. Nothing was duplicated in hardware; the values were simply copied into Prime Video's control block and replaced with Gmail's. When you switch back, the arrow runs the other way. Register values throughout the simulation are synthetic teaching values, not instructions executed by your browser.
Real processors have far more than four registers — dozens of general purpose ones, plus floating point and vector registers — which is one reason a switch costs real time. There is simply a lot to copy.
Context switching is pure overhead; no useful user-level work is done during the switch. The time spent switching is known as the "cost".
A conceptual formula for this cost is:
Switch Time = Save Time + Schedule Time + Load Time
For example: If a process runs for 10ms and a context switch takes 1ms, the total time for that cycle is 11ms. The CPU efficiency is 10ms / 11ms ≈ 90.9%. If switches become too frequent, this overhead can significantly degrade system performance.