Memory, Processes & Variables

How JavaScript programs use RAM, what a process is, and how variables store values in memory.

1 — How a Program Runs

RAM (Random Access Memory)

RAM is temporary, fast storage your computer uses while it's on. A typical machine has 4–32 GB. When you run a program, the OS loads it into RAM to execute it.

Process

When a program is running, it becomes a process — an active instance with its own slice of RAM allocated by the OS. For example, a Node.js script might be given 400 MB of RAM to work within.

Memory allocation

Within that allocated memory, JavaScript creates "buckets" (memory addresses) to hold values. A variable is simply a named label for one of those memory buckets.

RAM is your computer's workspace. The CPU can only work on things that are in RAM — so when you run a program, the OS loads it into RAM. Many programs share RAM simultaneously, each in its own isolated region.

Now let's zoom into one running program — a single process — and see how its memory is organized internally.

When the OS gives your program 400 MB of RAM, that memory is divided into these five segments. The key two for JavaScript are the stack (where let a = 10 lives — local variables, fast, auto-cleaned) and the heap (where objects and arrays live — flexible size, managed by the garbage collector).

2 — Variables: named memory buckets

Each line of JS is one instruction. Declaring a variable tells the engine to reserve a memory location, give it a name, and store a value there.

// One instruction: reserve memory, name it "a", store 10
let a = 10;
 
// Another bucket named "name", storing a string
let name = "Alice";
 
// Read from memory — returns 10
console.log(a);

Each let, const, or var declaration is one instruction. The JS engine executes instructions top-to-bottom, one at a time.

3 — Variable keywords compared

const age = 25;      // cannot be reassigned
let score = 0;       // can update: score = score + 1
var old = "legacy";  // avoid in modern JS

4 — The full picture

// Program starts → OS allocates RAM (e.g. 400 MB)
// JS engine starts inside that memory space
 
const price = 99;                // bucket "price" → stores 99
const tax = 0.18;                // bucket "tax"   → stores 0.18
const total = price * (1 + tax); // new bucket, computed value
 
console.log(total);              // reads bucket "total" → 116.82
 
// Program ends → OS reclaims that RAM

Key Mental Model additions:

• "code goes to RAM" — more precisely, when you run a program, the OS loads it into RAM and creates a process for it.
• "RAM has a limit like 4 GB" — RAM is a fixed hardware resource (4 GB, 16 GB, etc.), but any single process only gets a portion of it (e.g. 400 MB), not all of it.
• "bucket with a name" — that's actually a great analogy. A variable is a named label pointing to a memory address (the bucket). The name lets you read or update the value later without knowing the raw address.
• "one line = one instruction" — mostly correct for simple statements like let a = 10, though some multi-line expressions count as one instruction too. The core idea is right: JS executes sequentially, top to bottom.

[!TIP] Prefer const by default in modern JS — only use let when you actually need to reassign the variable. Avoid var entirely.

5 — Process, Thread & Scheduler

Now the biggest concept to understand — how does the OS decide who runs when, and what are threads?

Process vs thread vs scheduler

• Process — when you run node app.js, the OS creates a process. It allocates a chunk of RAM (say 400 MB), copies the program code into it, and gives the process a unique ID (PID). Processes are completely isolated — one process cannot touch another's memory.
• Thread — a thread is the actual unit of execution inside a process. Think of the process as a house, and threads as the workers inside it. All threads share the same heap (objects, data) but each has its own stack (its own sequence of function calls). A multi-threaded process like Chrome runs many threads at once.
• OS Scheduler — you may have 100 threads but only 4 CPU cores. The scheduler decides which threads run on which core, switching every few milliseconds (a "context switch" — saving one thread's state, restoring another's). This happens so fast it feels like everything runs simultaneously.

JavaScript's twist — JS is deliberately single-threaded

There is only one main thread. Instead of using multiple threads for concurrency, it uses the event loop: long-running tasks (like fetch() or setTimeout) are handed off to the OS/browser to run in the background. When they finish, their callback is placed in a queue. The event loop watches the call stack — when it's empty, it pushes the next callback in. This is why JS never blocks, even on a single thread.